From rem-conf-request@es.net Thu Feb 01 03:48:57 1996 Received: from www45.inria.fr by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Feb 1996 00:48:03 -0800 Received: by www45.inria.fr (8.6.12/8.6.12) id JAA02881; Thu, 1 Feb 1996 09:47:44 +0100 Message-Id: <199602010847.JAA02881@www45.inria.fr> To: rem-conf@es.net Subject: RealAudio and RTP ? Date: Thu, 01 Feb 1996 09:47:43 +0100 From: Philipp Hoschka - - ------------------------------------------------------------------------- PROGRESSIVE NETWORKS ANNOUNCES OPEN REALAUDIO ARCHITECTURE Progressive Networks and Netscape Announce Support for RTP and Joint Support for Progressive Networks Audio Protocol SEATTLE, January 31, 1996 Progressive Networks, makers of RealAudio, the leading streaming multimedia delivery system for the Internet, today announced that Netscape Communications Corp. and Progressive will work together to define open streaming audio protocols for the Internet. Progressive Networks also voiced strong support for Netscape's LiveMedia Real-time Transport Protocol (RTP) initiatives for the delivery of multimedia over the Internet. These efforts will allow users to interoperate audio and video in Internet-based applications. Progressive Networks plans to publish details of its open architecture, including protocols, by mid-year. "This is the right step at the right time," said Rob Glaser, president and CEO of Progressive Networks. "With more than 3,000,000 RealAudio players installed and downloads running at 25,000 players per day, RealAudio has become a defacto standard. Now is the time for us to turn RealAudio into an open, industry standard." Progressive Networks Supports Open Audio Protocol "We see Progressive Networks as a leader in the delivery of audio content over the Internet," said Jim Barksdale, president and CEO at Netscape. "We are ethusiastic about working with PN in developing streaming media standards for the Internet." "As a company we are committed to open standards, and having Netscape support our activities as well as PN supporting LiveMedia RTP initiatives is a tremendous vote of confidence for both our organizations," said Glaser. Today's announcement builds on the announced RealAudio 2.0 open architecture which allows third-party application developers to take advantage of the RealAudio System. Third-party application developers have access to the playback engine API, and the coder/decoder API. The open architecture allows integration with popular Web browser technology. For example, the Netscape Plug-In can be used transparently to include RealAudio into Netscape Navigator 2.0 applications. RealAudio software from Progressive Networks is available on the Internet at the Progressive Networks World Wide Web page (http://www.RealAudio.com/). Support of the Netscape Initiative Progressive Networks supports Netscape's efforts to develop a real-time protocol for providing point-to-point network functions suitable for applications transmitting real-time data such as audio. Progressive Networks, based in Seattle, develops and markets software products and services designed to enable users of personal computer and other digital devices to send and receive audio and audio-based multimedia using the existing Internet infrastructure. The RealAudio System consists of: the RealAudio player, which allows Internet users to access audio for instant playback; the RealAudio server, which lets content providers distribute audio or audio-based content over the Internet; and the RealAudio encoder which prepares audio programming for distribution. RealAudio is a trademark of Progressive Networks Navigator and LiveMedia are trademarks of Netscape Communications Corp. - ------- End of Forwarded Message ------- End of Unsent Draft From rem-conf-request@es.net Thu Feb 01 09:27:53 1996 Received: from linac.fnal.gov by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Feb 1996 06:27:19 -0800 Received: from d0tokensun.fnal.gov by linac.fnal.gov with SMTP id AA03306 (5.67b/IDA-1.5 for rem-conf@es.net); Thu, 1 Feb 1996 08:27:11 -0600 Received: by d0tokensun.fnal.gov (4.1/SMI-4.1) id AA12965; Thu, 1 Feb 96 08:24:48 CST Date: Thu, 1 Feb 96 08:24:48 CST From: cisko@d0tokensun.fnal.gov (Greg Cisko) Message-Id: <9602011424.AA12965@d0tokensun.fnal.gov> To: winickj@interlog.com, steve@vigra.com, roediger@hep.net Subject: Re: Canon VC-C1 Cc: rem-conf@es.net > From: roediger@hep.net (Gary Roediger) > Watch out for repairs on the VC-1. It is a great camera but if you every need > to repair it .... My SGI ate the Indy Cam and VC-1. SGI replace my Indy Cam > in 2 days. Cannon on the other hand -- they gave me a number and address at > Cannon in NJ. -- they in turn said they did not handle repairs and gave me a > local Chicago third party repair. It was sent to them and after many > weeks they sent it back saying they don't repair VC-1's. (This was after they > asked us to ship the power brick for the camera since they did not have one.) > Cannon was recontacted and gave us the original repair address in NJ - > this time they took it but then said they needed a check up front before repair. > This is a Dept of Energy site and with the government credit rating > these days .... > > I guess Cannon never expected any of these to fail but another group here had > a similar experience with their VC-1. I am in the other group (that Gary mentions) that had the VC-C1 camera repaired. Our camera made it back to the proper CANON repair facillity some time ago. (Much more than a month). I just got a phone call from CANON. They now say that the panning mechinism is also broken & I need to re-submit my purchase request for a higher amount. The camera was sent for repair because of no video output. The panning mechinism was the only this that was left working. I have to call them & "calmly" discuss the situation with them. The repair story is far from over... Greg Cisko Fermi National Acceletator Labratory > > Gary Roediger > From rem-conf-request@es.net Thu Feb 01 10:03:16 1996 Received: from qucis.queensu.ca by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Feb 1996 07:02:33 -0800 Received: from teaspoon.qucis.queensu.ca by qucis.queensu.ca (5.x/SMI-SVR4-qs1.6) id AA21609; Thu, 1 Feb 1996 10:02:15 -0500 Received: by teaspoon.qucis.queensu.ca (SMI-8.6/SMI-SVR4-qc1.3) id KAA06781; Thu, 1 Feb 1996 10:02:13 -0500 Date: Thu, 1 Feb 1996 10:02:12 -0500 (EST) From: Zhenjun Zhu X-Sender: zhuz@teaspoon To: rem-conf@es.net Subject: Question regarding the RTP implementation. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I am wondering that for RTP what type of implementation would be the most appropriate: [1] Simply integrated into application code design. [2] A single layer which provides applications with interfaces. [3] Interfaces implemented as system calls and code running in kernel. I velieve the different between [2] and [3] is whether to move the code into Kernel or not. Between [1] and [2], would there be an differences in terms of performance? Thanks. ************************************************** Zhenjun Zhu Graduate Student Department of Computing and Information Science Queen's University, Kingston, Canada zhuz@qucis.queensu.ca ************************************************** From rem-conf-request@es.net Thu Feb 01 10:10:21 1996 Received: from hermes.research.kpn.com by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Feb 1996 07:09:41 -0800 Received: from dnlts0.research.kpn.com by research.kpn.com (PMDF V4.3-11 #7381) id <01I0PE18T8ZK008R3W@research.kpn.com>; Thu, 01 Feb 1996 16:09:35 +0100 Received: from lsdm02.ms.research.kpn.com by dnlts0.research.kpn.com (PMDF V4.3-11 #7381) id <01I0PE1XDGU891WZ6F@dnlts0.research.kpn.com>; Thu, 01 Feb 1996 16:10:07 +0100 Date: Thu, 01 Feb 1996 16:05 +0100 From: "Dort, M. van" Subject: Re: RealAudio and RTP ? To: Ross Finlayson , rem conf mailing list Message-id: <01I0PE1XFCCY91WZ6F@dnlts0.research.kpn.com> X-Envelope-to: rem-conf@es.net MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Posting-date: Thu, 01 Feb 1996 16:05 +0100 Hi Ross, In ITU H.323 adopted RTP because we would like to have interworking with Internet products. I therefore would not like giving up RTP. It is always the case that there are companies conforming to standards and companies, which try to set their own standard. Publicity helps in those cases of course. (/5). Mascha van Dort KPN Research P.S. Do you have the address of the "voice on the net" mailing list? ---------- > From: Ross Finlayson > To: dort; Philipp Hoschka; rem-conf > Subject: Re: RealAudio and RTP ? > Date: Thursday 1 February 1996 14:09 > > > Just to make things clear here - the "RTP" mentioned in this announcement > isn't the IETF "RTP" protocol, is it? It sounds like it's actually > something else that Netscape (or some other company that they've recently > acquired) cooked up on their own. Does anyone on this list know more about > this "LiveMedia Real-Time Transport Protocol"? > > This highlights a major issue that I'm somewhat surprised has not yet been > discussed much on "rem-conf". In recent months the PC world has been > generating a plethora of mysterious audio/video transport > protocols/encodings for the Internet. In fact, from following the > discussions on the "voice on the net" mailing list digest (which covers > these things), it seems that almost every week some new company out there > announces a new audio (usually) or video application. (Of these, RealAudio > seems to be the most popular.) To their credit, many of these products have > very nice user interfaces, and appear to perform well (from the perspective > of the user), even over low-bandwidth (14.4 or 28.8) connections. But they > currently make little or no attempt to interoperate with other products. > Also, most of them ignore multicast (although some companies mention plans > to develop what would effective be their own, application-specific, > multicast routing architecture - ugh!). And who knows what these things are > actually doing to the underlying Internet? (As far as I can tell, most of > these products use UDP rather than TCP.) > > It's encouraging to hear Progressive Networks say that they plan to publish > details of their "RealAudio protocol architecture", but left unanswered are > the obvious questions about terms of licensing and change control. > > So what can/should we do about this? The question we have to ask ourselves > is: If the IETF-developed RTP protocol and encodings are being widely > ignored by the developer community, then how relevant are they? > > It's unfortunate that there doesn't seem to be an AVT session scheduled for > the upcoming Los Angeles IETF meeting, because I feel that this issue has > become so prominent that we can no longer avoid discussing it. > > Here are some possible approaches (not all mutually exclusive) that we could > take: > > 1/ Give up. The IETF gets out of the business of defining AVT standards, > and just lets the marketplace determine the standards. > I don't consider this option particularly satisfying, to put it > mildly. The IETF is the strongest voice out there for interoperability, and > we should at least continue to encourage this as a goal. Also, none of the > other efforts out there seems to have a credible multicast story. > > 2/ Ignore these other efforts, in the hope that they'll eventually either > disappear (unlikely!) or be absorbed by the IETF standards. > The problem with this approach is that even in the (unlikely, IMHO) > event that the final outcome is favorable to us, it'd probably take a > lengthy period of time, and we'd probably still end up requiring messy > translation/encapsulation mechanisms. Taken all round, everyone would lose. > > 3/ Adopt certain of these outside-developed protocols (e.g., "RealAudio") as > alternative standards, or at the very least allow them to be published as > informational RFCs. (I may not be using the right IETF terms here.) (As I > noted above, licensing and change control issues arise here, though...) > > 4/ Make our (IETF) protocols more attractive for the masses (the > low-bandwidth 'leaves' of the Internet) by demonstrating and encouraging > their use over low-bandwidth connections (such as 28.8 kbps), as well as on > the higher-bandwidth links that we're used to. E.g., start getting serious > about hierarchical encoding. (This is something I suggested on the "mbone" > list last December. Jon Crowcroft also noted at the time that UCL's RAT > project has this goal in mind.) > > 5/ Try to raise the profile of the IETF protocols in the industry as a > whole. One way to do this would be to publicize an ongoing series of > interoperability tests between different products - similar to the old > "Interop". (One difference, however, is that these tests could be held over > the global Internet rather than in one location - thereby reducing costs.) > Conforming products - and *only* those products - could be publically > branded as "Internet standard", or some similar designation (our equivalent > of "Intel inside" :-) > > Personally, I'd like to see a combination of options 4/ and 5/, with perhaps > a concession to 3/ in some cases. Option 1/ would, I feel, lead to a > technological setback for the field as a whole, and 2/ runs the risk of > wasting a huge amount of human resources. > > Comments and discussion? > > Ross. > > From rem-conf-request@es.net Thu Feb 01 11:00:31 1996 Received: from rc4.vub.ac.be (actually mailhost.vub.ac.be) by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Feb 1996 07:59:23 -0800 Received: from is2e.vub.ac.be (is2e [134.184.15.6]) by rc4.vub.ac.be (8.6.10/3.4.2.ap (rc4)) id RAA10686; Thu, 1 Feb 1996 17:02:36 +0100 Received: by is2e.vub.ac.be (5.61/BFUCC-920211) id AA04375; Thu, 1 Feb 96 16:58:48 +0100 From: hw45289@is1.vub.ac.be (KEPPENS ACHIEL) Message-Id: <9602011558.AA04375@is2e.vub.ac.be> Subject: To: rem-conf@es.net Date: Thu, 1 Feb 1996 16:58:47 +0100 (MET) X-Mailer: ELM [version 2.4 PL23c] Content-Type: text Content-Length: 236 please UNSUBSCRIBE ME -- ACHIEL KEPPENS (hw45289@is2.vub.ac.be) Student Communicatiewetenschappen Vrije Universiteit Brussel -------------------------------------- From rem-conf-request@es.net Thu Feb 01 11:20:53 1996 Received: from Xenon.Stanford.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Feb 1996 05:12:51 -0800 Received: from rsf.vip.best.com (rsf.vip.best.com [204.156.129.162]) by Xenon.Stanford.EDU (8.7.1/8.7.1) with SMTP id FAA11290; Thu, 1 Feb 1996 05:09:43 -0800 (PST) Date: Thu, 1 Feb 1996 05:09:43 -0800 (PST) Posted-Date: Thu, 1 Feb 1996 05:09:43 -0800 (PST) Message-Id: <1.5.4b11.16.19960201050936.34b7c8d4@pop.best.com> X-Sender: rsf@pop.best.com X-Mailer: Windows Eudora Light Version 1.5.4b11 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Philipp Hoschka , rem-conf@es.net From: Ross Finlayson Subject: Re: RealAudio and RTP ? Just to make things clear here - the "RTP" mentioned in this announcement isn't the IETF "RTP" protocol, is it? It sounds like it's actually something else that Netscape (or some other company that they've recently acquired) cooked up on their own. Does anyone on this list know more about this "LiveMedia Real-Time Transport Protocol"? This highlights a major issue that I'm somewhat surprised has not yet been discussed much on "rem-conf". In recent months the PC world has been generating a plethora of mysterious audio/video transport protocols/encodings for the Internet. In fact, from following the discussions on the "voice on the net" mailing list digest (which covers these things), it seems that almost every week some new company out there announces a new audio (usually) or video application. (Of these, RealAudio seems to be the most popular.) To their credit, many of these products have very nice user interfaces, and appear to perform well (from the perspective of the user), even over low-bandwidth (14.4 or 28.8) connections. But they currently make little or no attempt to interoperate with other products. Also, most of them ignore multicast (although some companies mention plans to develop what would effective be their own, application-specific, multicast routing architecture - ugh!). And who knows what these things are actually doing to the underlying Internet? (As far as I can tell, most of these products use UDP rather than TCP.) It's encouraging to hear Progressive Networks say that they plan to publish details of their "RealAudio protocol architecture", but left unanswered are the obvious questions about terms of licensing and change control. So what can/should we do about this? The question we have to ask ourselves is: If the IETF-developed RTP protocol and encodings are being widely ignored by the developer community, then how relevant are they? It's unfortunate that there doesn't seem to be an AVT session scheduled for the upcoming Los Angeles IETF meeting, because I feel that this issue has become so prominent that we can no longer avoid discussing it. Here are some possible approaches (not all mutually exclusive) that we could take: 1/ Give up. The IETF gets out of the business of defining AVT standards, and just lets the marketplace determine the standards. I don't consider this option particularly satisfying, to put it mildly. The IETF is the strongest voice out there for interoperability, and we should at least continue to encourage this as a goal. Also, none of the other efforts out there seems to have a credible multicast story. 2/ Ignore these other efforts, in the hope that they'll eventually either disappear (unlikely!) or be absorbed by the IETF standards. The problem with this approach is that even in the (unlikely, IMHO) event that the final outcome is favorable to us, it'd probably take a lengthy period of time, and we'd probably still end up requiring messy translation/encapsulation mechanisms. Taken all round, everyone would lose. 3/ Adopt certain of these outside-developed protocols (e.g., "RealAudio") as alternative standards, or at the very least allow them to be published as informational RFCs. (I may not be using the right IETF terms here.) (As I noted above, licensing and change control issues arise here, though...) 4/ Make our (IETF) protocols more attractive for the masses (the low-bandwidth 'leaves' of the Internet) by demonstrating and encouraging their use over low-bandwidth connections (such as 28.8 kbps), as well as on the higher-bandwidth links that we're used to. E.g., start getting serious about hierarchical encoding. (This is something I suggested on the "mbone" list last December. Jon Crowcroft also noted at the time that UCL's RAT project has this goal in mind.) 5/ Try to raise the profile of the IETF protocols in the industry as a whole. One way to do this would be to publicize an ongoing series of interoperability tests between different products - similar to the old "Interop". (One difference, however, is that these tests could be held over the global Internet rather than in one location - thereby reducing costs.) Conforming products - and *only* those products - could be publically branded as "Internet standard", or some similar designation (our equivalent of "Intel inside" :-) Personally, I'd like to see a combination of options 4/ and 5/, with perhaps a concession to 3/ in some cases. Option 1/ would, I feel, lead to a technological setback for the field as a whole, and 2/ runs the risk of wasting a huge amount of human resources. Comments and discussion? Ross. From rem-conf-request@es.net Thu Feb 01 13:38:06 1996 Received: from atg.apple.com by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Feb 1996 10:37:06 -0800 Received: from [17.255.9.185] (max1.atg.apple.com [17.255.9.185]) by atg.apple.com (8.7.2/8.6.12) with SMTP id KAA26686; Thu, 1 Feb 1996 10:38:01 -0800 (PST) Date: Thu, 1 Feb 1996 10:38:01 -0800 (PST) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-URL: http://interstice.com/~max/ To: Ross Finlayson From: max@atg.apple.com (Mark Q. Maxham) Subject: Re: RealAudio and RTP ? Cc: rem-conf@es.net At 5:09 AM 2/1/96, Ross Finlayson wrote: > Just to make things clear here - the "RTP" mentioned in this announcement > isn't the IETF "RTP" protocol, is it? A similar announcement I got yesterday explicitly identifies RFC 1889: ----- NETSCAPE ANNOUNCES NEW REAL-TIME AUDIO AND VIDEO FRAMEWORK FOR INTERNET APPLICATIONS [lots of junk deleted] "In addition, eleven technology-leading companies announced plans to support Netscape LiveMedia, which is based on open standards and interfaces that will enable Netscape and third-party real-time audio and video products to interoperate. Companies that announced their support are Progressive Networks, Adobe Systems, Digital Equipment Corp., Macromedia, NetSpeak, OnLive!, Precept, Silicon Graphics, Inc., VDOnet, VocalTec and Xing. The Netscape LiveMedia framework will be based on the Internet Realtime Transport Protocol (RTP), RFC number 1889, and other open audio and video standards such as MPEG, H.261 and GSM to enable products from these and other companies to work together seamlessly, providing users with a range of real-time audio and video capabilities on the Internet." ----- So ... sounds like "our" RTP to me. max From rem-conf-request@es.net Thu Feb 01 14:56:10 1996 Received: from gw1.att.com by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Feb 1996 11:55:15 -0800 Received: from arch4.ho.att.com by ig2.att.att.com id AA28966; Thu, 1 Feb 96 14:55:34 EST Received: from dahlia (dahlia.ho.att.com) by arch4.ho.att.com (4.1/EMS-1.2 GIS) id AA02739; Thu, 1 Feb 96 14:43:18 EST Received: by dahlia (4.1/EMS-1.1 SunOS) id AA05012; Thu, 1 Feb 96 14:45:19 EST Date: Thu, 1 Feb 96 14:45:19 EST From: shur@arch4.ho.att.com Message-Id: <9602011945.AA05012@dahlia> To: andrew@andrew.triumf.ca, metzger@scl.ameslab.gov Subject: Re: vcr binaries for OSF, Irix ?? Cc: rem-conf@es.net Has anyone got pointers to SunOS or Solaris binaries for vcr? Thanks, David Shur ------------- > > I am also interested in Irix binaries that work. I have been able to > compile it after making some minor changes but the resulting binary > does not work. > > Most of the problems involved scoping issues like declaring a variable inside > a block and then trying to use it outside the block. There are also a > couple of extra newlines in num_display.tcl. > From rem-conf-request@es.net Thu Feb 01 15:27:45 1996 Received: from Xenon.Stanford.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Feb 1996 12:27:12 -0800 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by Xenon.Stanford.EDU (8.7.1/8.7.1) with SMTP id MAA15772 for ; Thu, 1 Feb 1996 12:27:18 -0800 (PST) Date: Thu, 1 Feb 1996 12:27:18 -0800 (PST) Posted-Date: Thu, 1 Feb 1996 12:27:18 -0800 (PST) Message-Id: <1.5.4b11.16.19960201122707.a277ddbc@pop.best.com> X-Sender: rsf@pop.best.com X-Mailer: Windows Eudora Light Version 1.5.4b11 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: Ross Finlayson Subject: Re: RealAudio and RTP ? At 10:38 AM 2/1/96 -0800, Mark Q. Maxham wrote: >A similar announcement I got yesterday explicitly identifies RFC 1889: ... >So ... sounds like "our" RTP to me. Great news - it's encouraging to hear this. Of course, though, this announcement seems to be talking about future plans, rather than the myriad of systems already out there in PC-land. The role, if any, of the IETF in these future activities is something that still needs to be discussed, I think. Also, Mascha van Dort wrote: >P.S. Do you have the address of the "voice on the net" mailing list? majordomo@pulver.com subscribe von Ross. From rem-conf-request@es.net Thu Feb 01 15:43:21 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Feb 1996 12:42:46 -0800 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id MAA00514; Thu, 1 Feb 1996 12:42:19 -0800 Message-Id: <199602012042.MAA00514@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: max@atg.apple.com (Mark Q. Maxham) cc: Ross Finlayson , rem-conf@es.net Subject: Re: RealAudio and RTP ? In-reply-to: Your message of "Thu, 01 Feb 1996 10:38:01 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Feb 1996 12:42:18 -0800 From: "Amancio Hasty Jr." We should ask Netscape for a technical description of what they mean by RTP . It could be RTP with the following propieratory payloads and these "minor" extensions and of course you have to pay for the software codec ... 8) Amancio >>> Mark Q. Maxham said: > At 5:09 AM 2/1/96, Ross Finlayson wrote: > > Just to make things clear here - the "RTP" mentioned in this announcement > > isn't the IETF "RTP" protocol, is it? > > A similar announcement I got yesterday explicitly identifies RFC 1889: > ----- > NETSCAPE ANNOUNCES NEW REAL-TIME AUDIO AND VIDEO FRAMEWORK FOR INTERNET > APPLICATIONS > > [lots of junk deleted] > > "In addition, eleven technology-leading companies announced plans to support > Netscape LiveMedia, which is based on open standards and interfaces that > will enable Netscape and third-party real-time audio and video products to > interoperate. Companies that announced their support are Progressive > Networks, Adobe Systems, Digital Equipment Corp., Macromedia, NetSpeak, > OnLive!, Precept, Silicon Graphics, Inc., VDOnet, VocalTec and Xing. The > Netscape LiveMedia framework will be based on the Internet Realtime > Transport Protocol (RTP), RFC number 1889, and other open audio and video > standards such as MPEG, H.261 and GSM to enable products from these and > other companies to work together seamlessly, providing users with a range > of real-time audio and video capabilities on the Internet." > ----- > > So ... sounds like "our" RTP to me. > > max > > From rem-conf-request@es.net Thu Feb 01 19:44:37 1996 Received: from gatekeeper.sprintlabs.com by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Feb 1996 16:43:52 -0800 Received: from [199.2.53.28] by gatekeeper.sprintlabs.com with SMTP id AA04046 (5.67b/IDA-1.5); Thu, 1 Feb 1996 16:42:34 -0800 Date: Thu, 1 Feb 1996 16:42:34 -0800 Message-Id: <199602020042.AA04046@gatekeeper.sprintlabs.com> X-Sender: aollikai@gatekeeper Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net, videophone@es.net From: aollikai@sprintlabs.com (Ari Ollikainen) Found on InSoft's HomePage (http://www.insoft.com): NETSCAPE ANNOUNCES NEW REAL-TIME AUDIO AND VIDEO FRAMEWORK FOR INTERNET APPLICATIONS January 31, 1996 MOUNTAIN VIEW, California Netscape Communications Corporation (NASDAQ: NSCP) today announced Netscape LiveMedia, a standards-based framework for bringing real-time audio and video to the Netscape open software platform. As the cornerstone of its new framework, Netscape announced the signing of a definitive agreement to acquire InSoft, Inc., a leader in network-based communications and collaborative multimedia software for the enterprise. InSoft's applications include Communique! for desktop collaboration and videoconferencing, InSoft Network Television or INTV! for distributed digital video, and CoolTalk and CoolView for Internet audio, video and data communications on Windows, Windows95 and UNIX based platforms. Netscape plans to use InSoft's technology to create the Netscape LiveMedia framework, which it plans to make a standard component in future Netscape clients, servers and tools. Netscape LiveMedia framework will enable users to have easier access to new Internet applications such as audio and video on-demand, real-time video conferencing and Internet telephony. In addition, eleven technology-leading companies announced plans to support Netscape LiveMedia, which is based on open standards and interfaces that will enable Netscape and third-party real-time audio and video products to interoperate. Companies that announced their support are Progressive Networks, Adobe Systems, Digital Equipment Corp., Macromedia, NetSpeak, OnLive!, Precept, Silicon Graphics, Inc., VDOnet, VocalTec and Xing. The Netscape LiveMedia framework will be based on the Internet Realtime Transport Protocol (RTP), RFC number 1889, and other open audio and video standards such as MPEG, H.261 and GSM to enable products from these and other companies to work together seamlessly, providing users with a range of real-time audio and video capabilities on the Internet. Netscape will publish the LiveMedia framework on the Internet, openly license key technology components of it, and work with the Internet standards bodies to facilitate the adoption of this technology as a formal Internet standard. "By integrating InSoft's technology within our existing software architectures, we can extend the Netscape software platform into a foundation for real-time Internet and Intranet communications," said Jim Barksdale, president and CEO of Netscape. "Through this agreement with InSoft, Netscape will also gain InSoft's great team of people who bring best-of-breed expertise in delivering real-time audio/video applications to the enterprise." "The Internet is a strategic component of our open, enterprise approach to collaborative multimedia," said Dan Harple, chairman and CEO of InSoft. "Real-time multimedia collaboration helps to bring people together across a network, a goal that both Netscape and InSoft share. Without question, we are extremely excited about joining the Netscape team and helping to develop the Netscape LiveMedia framework." Netscape intends to purchase 100 percent of InSoft, a privately held company, for 1.96 million shares of Netscape stock (adjusted to reflect the Netscape 2-for-1 stock split which was approved by shareholders on January 23, 1996), to be accounted for as a pooling of interests. The deal is expected to close on or before March 31, 1996. InSoft, Inc., located in Mechanicsburg, Pennsylvania, was founded in 1992 by Dan Harple and Rich Pizzarro to develop and market collaborative multimedia software products for the expanding desktop workstation market. The company currently employs 71 people. InSoft's OpenDVE Collaborative Multimedia Framework enables cross-platform collaboration between PCs and UNIX workstations, transparent connectivity between a wide range of networks, and interoperability between a range of video offerings. Netscape plans to integrate InSoft's products in two phases. In the first phase, the combined companies will develop the LiveMedia framework and continue to promote InSoft's OpenDVE software architecture and development toolkits; Communique!, INTV!, CoolTalk and CoolView applications, and the GlobalConference telecommunications gateway. In the second phase later in 1996, Netscape plans to integrate InSoft's real-time audio and video capabilities into future versions of Netscape Navigator and Netscape servers. In addition, Netscape expects that third-party developers will offer a wide variety of add-on audio and video products based on the LiveMedia framework. Netscape also announced today that it has signed an agreement with Voxware, Inc., to license that company's compression/decompression (codec) technology to plug into the Netscape LiveMedia framework. Codecs from other companies can also be incorporated into the extensible framework. Voxware, Inc. is a privately-held developer of advanced voice processing software, based in Princeton, NJ. Voxware's ToolVox digital voice technology enables high-quality, real-time voice communication across the Web, while requiring only 2400 bps of bandwidth. Using the ToolVox cross-platform encoder and player software, developers can compress voice 53:1; download or stream voice files in real time and add a variety of voice effects. This combination of compression and quality simplifies adding voices to the Web. This technology will help to provide widespread, reliable voice delivery to any user with a Web connection. The incorporation of the Voxware codec in LiveMedia is an example of how this modular framework can accommodate technologies from various companies. "We're delighted that our agreement with Netscape will make ToolVox a key component of the core technology framework for Netscape LiveMedia," said Michael Goldstein, president and CEO of Voxware. "We look forward to working together to make real-time voice communications a natural and everyday part of every Web user's experience." "Enabling users to communicate and work together from any location -- and in real time -- extends the Internet's power and reach to a new level," said Marc Andreessen, vice president of technology at Netscape. "The Netscape LiveMedia framework will make a number of real-time audio and video applications available to Internet users. InSoft and Voxware are important to Netscape's strategy to deliver products based on LiveMedia, and we will work with the technology-leading companies who are supporting this interoperable approach to make real-time audio and video applications an immediate reality." Netscape LiveMedia represents a commitment to open Internet-supported protocols and content definitions that transcend any single vendor, including Netscape. Vendors adopting the LiveMedia Internet standards will be able to offer products that interoperate with other LiveMedia compatible products, making it easy for users to take advantage of real-time audio and video capabilities on the Internet. Netscape Communications Corporation is a premier provider of open software for linking people and information over enterprise networks and the Internet. The company offers a full line of Netscape Navigator clients, Netscape servers, development tools and Netscape Internet Applications to create a complete platform for next-generation, live online applications. Traded on Nasdaq under the symbol "NSCP", Netscape Communications Corporation is based in Mountain View, California. Additional information on Netscape Communications Corporation is available on the Internet at http://home.netscape.com, by sending email to info@netscape.com or by calling 415-528-2555. Information on InSoft, Inc. is available on the Internet at http://www.insoft.com or by calling 717-730-9501. Further information on Voxware is available at http://www.voxware.com Netscape Communications, the Netscape Communications logo, Netscape Navigator, Netscape LiveMedia, Netscape and Netscape Internet Applications are trademarks of Netscape Communications Corporation. All other product names are trademarks of their respective owners. From rem-conf-request@es.net Thu Feb 01 20:03:43 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Feb 1996 17:03:15 -0800 Received: from judy (aspen.precept.com) by precept.com (5.x/SMI-4.1) id AA19692; Thu, 1 Feb 1996 17:03:12 -0800 Date: Thu, 1 Feb 1996 17:03:12 -0800 Message-Id: <9602020103.AA19692@precept.com> X-Sender: judy@pophost.precept.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Ross Finlayson From: Judy Estrin Subject: Re: RealAudio and RTP ? Cc: rem-conf@es.net, judy@precept.com Ross, I read your message in response to the RealAudio/Netscape press releases and although I am not a direct participant on rem-conf (some of our sw developers are), I feel strongly about the points you make and thought I would respond directly. I assume that Netscape and/or Progressive will also respond. 1. The Netscape LiveMedia framework will be based on IETF's RTP! So if Progressive is committing to support LiveMedia, then they too need to support IETF RTP. In fact Netscape refers to RTPs RFC # in the press release that they issued yesterday. 2. We agree with your concerns about multiple proprietary approaches fragmenting the industry. In fact we just announced our first products that are based on RTP and are, we believe, the first commercially available implementation for Windows based PC's. I believe it is just a matter of time before you see broader industry acceptance and the Netscape endorsement will help accelerate this. 3. Steve Casner (who works here at Precept) wil look into your point about an AVT session at the IETF meeting in LA and will respond seperately 4. Your point #5 about interoperabilty testing is a good one and we would be happy to participate in and help organize this effort. So far we have verified interoperability with the latest VIC and VAT software. Judy Judy Estrin Precept Software, Inc. 21580 Stevens Creek Blvd., Suite 207 Cupertino, CA 95014 408 446-7600 From rem-conf-request@es.net Thu Feb 01 21:17:43 1996 Received: from decu13.triumf.ca by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Feb 1996 18:17:00 -0800 Received: by decu13.triumf.ca (5.65/DEC-Ultrix/4.3) id AA29139; Thu, 1 Feb 1996 18:16:43 -0800 Date: Thu, 1 Feb 1996 18:16:42 -0800 (PST) From: Andrew Daviel To: rem-conf@osi-west.es.net Subject: RealAudio ,video etc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A datapoint: A store here in town (www.doppler.com) is using Xing's (www.xingtech.com) video technology to point-to-point broadcast a loop of videotape, just to show it's possible. Seems to me if they must do that, multicast would keep the total bandwidth to 1 stream... Andrew Daviel email: advax@triumf.ca TRIUMF voice: 604-222-7376 4004 Wesbrook Mall fax: 604-222-7307 Vancouver BC http://andrew.triumf.ca/~andrew Canada V6T 2A3 49D14.7N 123D13.6W From rem-conf-request@es.net Thu Feb 01 22:42:42 1996 Received: from broon.off.connect.com.au by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Feb 1996 19:41:34 -0800 Received: from localhost (ggm@localhost) by broon.off.connect.com.au with SMTP id NAA01645 (8.6.12/IDA-1.6); Fri, 2 Feb 1996 13:41:24 +1000 X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs X-Authentication-Warning: broon.off.connect.com.au: Host localhost didn't use HELO protocol To: rem-conf@es.net, videophone@es.net In-reply-to: Your message of "Thu, 01 Feb 1996 16:42:34 PST." <199602020042.AA04046@gatekeeper.sprintlabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1640.823232482.1@connect.com.au> Date: Fri, 02 Feb 1996 13:41:23 +1000 Message-ID: <1642.823232483@connect.com.au> From: George Michaelson I think this is probably being felt by most of us as a mixed blessing. On the one hand, as "true believers" its really nice to see something as fundamental as the standards process and technical discussions migrate to deployed service. I think the RFC authors and contributors (I am not one) deserve acclaim for the work they have done in defining what is clearly going to be extremely popular and important "enabling technology" On the other hand, netscape/web is a model of explosive growth-of-use we might well have wanted to meet in 5 years time, and not right now. I suppose in the face of all the point-to-point proprietary methods this is the best of a bad choice. I would have preferred more explicit adoption of multicasting (which is distinct from RTP in this case surely?) and support for multicasting in Windows winsock stacks to be more widely dispersed and understood. Also I fear the lack of bandwidth-management control is going to become very visible, internet-wide as people find "batfones" are as simple as a web-click, 3 questions, and go... I know, nobody gets rich predicting imminent death of the network. I think this class of application really does change the state of play, and we might expect to see another knee in utilization/load graphs reflecting the release-date of code into the hands of the masses... -George -- George Michaelson | connect.com.au pty/ltd Email: ggm@connect.com.au | c/o AAPT, Phone: +61 7 3834 9976 | level 8, the Riverside Centre, Fax: +61 7 3834 9908 | 123 Eagle St, Brisbane QLD 4000 From rem-conf-request@es.net Fri Feb 02 00:20:41 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Feb 1996 21:20:11 -0800 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id VAA01020; Thu, 1 Feb 1996 21:19:43 -0800 Message-Id: <199602020519.VAA01020@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Andrew Daviel cc: rem-conf@osi-west.es.net Subject: Re: RealAudio ,video etc. In-reply-to: Your message of "Thu, 01 Feb 1996 18:16:42 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Feb 1996 21:19:41 -0800 From: "Amancio Hasty Jr." Well, you sort of have a point : Xing has their one MBONE-like technlogy in addition to point-to-point. Amancio >>> Andrew Daviel said: > > A datapoint: > > A store here in town (www.doppler.com) is using Xing's > (www.xingtech.com) video technology to point-to-point broadcast a loop of > videotape, just to show it's possible. Seems to me if they must do that, > multicast would keep the total bandwidth to 1 stream... > > Andrew Daviel email: advax@triumf.ca > TRIUMF voice: 604-222-7376 > 4004 Wesbrook Mall fax: 604-222-7307 > Vancouver BC http://andrew.triumf.ca/~andrew > Canada V6T 2A3 49D14.7N 123D13.6W > From rem-conf-request@es.net Fri Feb 02 09:41:22 1996 Received: from qucis.queensu.ca by osi-west.es.net with ESnet SMTP (PP); Fri, 2 Feb 1996 06:40:52 -0800 Received: from teaspoon.qucis.queensu.ca by qucis.queensu.ca (5.x/SMI-SVR4-qs1.6) id AA12414; Fri, 2 Feb 1996 09:40:43 -0500 Received: by teaspoon.qucis.queensu.ca (SMI-8.6/SMI-SVR4-qc1.3) id JAA23267; Fri, 2 Feb 1996 09:40:41 -0500 Date: Fri, 2 Feb 1996 09:40:39 -0500 (EST) From: Zhenjun Zhu X-Sender: zhuz@teaspoon To: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII It seems that I have problem getting this mailing list subscribed - I sent subscription requests to rem-conf-request@es.net number of times but I have not been added to the receiver list yet. Is anyone out there maintaining this list that can help me? Sorry for this non-technical mail in technical discussion. ************************************************** Zhenjun Zhu Graduate Student Department of Computing and Information Science Queen's University, Kingston, Canada zhuz@qucis.queensu.ca ************************************************** From rem-conf-request@es.net Fri Feb 02 11:06:59 1996 Received: from gw1.att.com by osi-west.es.net with ESnet SMTP (PP); Fri, 2 Feb 1996 08:06:30 -0800 Received: from arch4.ho.att.com by ig1.att.att.com id AA23497; Fri, 2 Feb 96 11:04:00 EST Received: from dahlia (dahlia.ho.att.com) by arch4.ho.att.com (4.1/EMS-1.2 GIS) id AA23421; Fri, 2 Feb 96 11:05:55 EST Received: by dahlia (4.1/EMS-1.1 SunOS) id AA28337; Fri, 2 Feb 96 11:07:57 EST Date: Fri, 2 Feb 96 11:07:57 EST From: shur@arch4.ho.att.com Message-Id: <9602021607.AA28337@dahlia> To: rem-conf@es.net, mccanne@ee.lbl.gov Subject: UDP buffer overflows when using vic Mbone tool at high bandwidth Cc: rustom@hogpa.att.com Any advice, hints etc. for the following problem would be appreciated: We are running the usual suite of Mbone tools on SParc 20s with Solaris 2.4. (vic2.7a27, wb1.59, vat4.0a2). In vic, when transmitting and when we crank up the max bandwidth and max frame rate all the way (to approx 3 Mbps and 30 f/s resp.), we observe a high rate of UDP packet drops (20-30%) for received packets. The CPU does not appear to be maxed out while this is happening. We see the same behavior on a single dedicated ethernet subnet/segment (with nothing else running) and ATM SVCs (we use Fore 100 Mbps Taxi SBA200 adapters) within the same subnet. Also the behavior was basically the same with 32 Meg of Ram and 96 Meg of Ram. One theory is that the stream buffers are getting exhausted and hence UDP dumps the packets on the floor rather than sending them up (down) the stream. We have tried to find a kernel variable that might let us increase the number of stream buffers but have been unable to do so up to this point. We don't know if this behavior is application related or how the system can be more optimally tuned. or know of some other reason why this is happening. Thanks for your help. David. From rem-conf-request@es.net Fri Feb 02 12:49:52 1996 Received: from ceres.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Fri, 2 Feb 1996 09:49:10 -0800 Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Fri, 2 Feb 1996 18:47:36 +0100 X-Mailer: exmh version 1.6.5 12/11/95 To: rem-conf@es.net From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: Color problems with SunVideo boards Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Feb 1996 18:47:31 +0100 Sender: schulzrinne@fokus.gmd.de Anybody has similar problems? Suggestions? ------- Forwarded Message From: Dorgham Sisalem Using the Sun VideoCard with JPEG or MPEG at high frame and data rates results in color stripes in the resulting pictures. This was noticed when using the same card with different cameras and different workstations (that is, SS10, SS20). dmesg results in the following informations: RTVC: Driver version 1.122 modified 94/06/02; compiled Jun 14 1994 at 16:01:12 rtvc0: compression engine rev. B2; asic rev. 3; Philips 7191; board rev. SUNW,501-2232-06REV50 SUNW,rtvc0 at sbus0: SBus slot 2 0x0 and SBus slot 2 0x10000 and SBus slot 2 0x20000 and SBus slot 2 0x30000 and SBus slot 2 0x40000 and SBus slot 2 0x400000 SBus level 5 sparc ipl 9 SUNW,rtvc0 is /iommu@f,e0000000/sbus@f,e0001000/SUNW,rtvc@2,0 Strangely, using another SunVideo card with the same Workstation and the sane camera did not result in the colour stripes, even though dmesg produced the same output. This problem has been noticed in two out of our three Sun VideoCards. ------- End of Forwarded Message From rem-conf-request@es.net Fri Feb 02 16:25:03 1996 Received: from venera.isi.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 2 Feb 1996 13:24:01 -0800 Received: from ash.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Feb 1996 13:23:57 -0800 Date: Fri, 2 Feb 1996 13:20:53 -0800 From: touch@ISI.EDU Posted-Date: Fri, 2 Feb 1996 13:20:53 -0800 Message-Id: <199602022120.AA15533@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-4) id ; Fri, 2 Feb 1996 13:20:53 -0800 To: rem-conf@es.net Subject: Re: UDP buffer overflows when using vic Mbone tool at high bandwidth X-Auto-Sig-Adder-By: faber@isi.edu > Any advice, hints etc. for the following problem would be appreciated: > > We are running the usual suite of Mbone tools on SParc 20s with Solaris > 2.4. (vic2.7a27, wb1.59, vat4.0a2). In vic, when transmitting and when > we crank up the max bandwidth and max frame rate all the way (to approx 3 > Mbps and 30 f/s resp.), we observe a high rate of UDP packet drops > (20-30%) for received packets. The CPU does not appear to be maxed out > while this is happening. > > We see the same behavior on a single dedicated ethernet subnet/segment > (with nothing else running) and ATM SVCs (we use Fore 100 Mbps Taxi > SBA200 adapters) within the same subnet. Also the behavior was > basically the same with 32 Meg of Ram and 96 Meg of Ram. > > One theory is that the stream buffers are getting exhausted and hence > UDP dumps the packets on the floor rather than sending them up (down) > the stream. We have tried to find a kernel variable that might let us > increase the number of stream buffers but have been unable to do so up > to this point. We don't know if this behavior is application related > or how the system can be more optimally tuned. or know of some other > reason why this is happening. If you're producing packets faster than you can consume them, no increase in the buffers will solve the problem. I believe this is the predominant issue. A secondary issue is that packets are dropped because the buffer overflows, even though there is idle BW at the receiver when no packets are available, i.e., as you point out, that the buffers are too small. Computing optimal buffer sizes when sources and sinks are likely to oscillate and "hammer" is hard. Instead, we can increase the effective (received packet) throughput in UDP 'netperf'-style tests by pacing the source. Doesn't this occur in the LBL tools? Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ From rem-conf-request@es.net Fri Feb 02 19:03:02 1996 Received: from faui40.informatik.uni-erlangen.de (actually 131.188.2.40) by osi-west.es.net with ESnet SMTP (PP); Fri, 2 Feb 1996 16:02:26 -0800 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id BAA28486 (8.7.2/7.5a-FAU);; Sat, 3 Feb 1996 01:02:21 +0100 (MET) From: Toerless Eckert Message-Id: <199602030002.BAA28486@faui40.informatik.uni-erlangen.de> Subject: Re: UDP buffer overflows when using vic Mbone tool at high bandwidth To: touch@ISI.EDU Date: Sat, 3 Feb 1996 01:02:16 +0100 (MET) Cc: rem-conf@es.net In-Reply-To: <199602022120.AA15533@ash.isi.edu> from "touch@ISI.EDU" at Feb 2, 96 01:20:53 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Another observation on my behalf with regards to buffering: SS20/71 with SunVideo running SunOS 5.4: CIF size h261 compression will max out at less than 20 frames per second, but the CPU is not fully loaded. I know for sure that the rate at which the sunvideo board can deliver uncompressed YUV (or RGB if that matters) CIF size video is 25 for PAL and 30 for NTSC. Just wondering what is happening here. Looks to me as if frames get lost between SunVideo and vic probably because of not enough buffering. At least i excpet vic to consume the CPU unless the maximum framerate of a grabber is achieved. Toerless From rem-conf-request@es.net Sat Feb 03 07:37:11 1996 Received: from basil.cdt.luth.se by osi-west.es.net with ESnet SMTP (PP); Sat, 3 Feb 1996 04:36:33 -0800 Received: (from hakanl@localhost) by basil.cdt.luth.se (8.6.12/8.6.12) id NAA01825 for rem-conf@es.net; Sat, 3 Feb 1996 13:36:19 +0100 Date: Sat, 3 Feb 1996 13:36:19 +0100 From: Hakan Lennestal Message-Id: <199602031236.NAA01825@basil.cdt.luth.se> To: rem-conf@es.net Subject: Re: UDP buffer overflows when using vic Mbone tool at high bandwidth Content-Length: 1040 shur@arch4.ho.att.com wrote: > > Any advice, hints etc. for the following problem would be appreciated: > > We are running the usual suite of Mbone tools on SParc 20s with Solaris > 2.4. (vic2.7a27, wb1.59, vat4.0a2). In vic, when transmitting and when > we crank up the max bandwidth and max frame rate all the way (to approx 3 > Mbps and 30 f/s resp.), we observe a high rate of UDP packet drops > (20-30%) for received packets. The CPU does not appear to be maxed out > while this is happening. The problem seem to be that vic's current implementation is somehow synchronized with and gives higher priority to the outgoing stream then handling the incomming streams. One solution is to use two instances of vic. One for receiving and one for transmitting. Scale down the window of the transmitting vic instance so it will only show your outgoing stream (that way you won't have to se the high loss rate on the incomming streams :-). The recevie only instance will most likely show no (or at least quite less) packet loss. o /Hakan From rem-conf-request@es.net Sat Feb 03 14:30:27 1996 Received: from ipoint.vlsi.uiuc.edu by osi-west.es.net with ESnet SMTP (PP); Sat, 3 Feb 1996 11:29:39 -0800 Received: from berserk.ipoint.uiuc.edu (berserk.vlsi.uiuc.edu) by ipoint.vlsi.uiuc.edu with SMTP id AA06156 (5.65c/IDA-1.4.4 for ); Sat, 3 Feb 1996 13:38:49 -0600 Received: by berserk.ipoint.uiuc.edu (SMI-8.6/SMI-SVR4) id NAA05295; Sat, 3 Feb 1996 13:29:55 -0600 From: ashfaq@ipoint.vlsi.uiuc.edu (Ashfaq Hossain) Message-Id: <199602031929.NAA05295@berserk.ipoint.uiuc.edu> Subject: SunVideo Hardware Decompression To: Toerless.Eckert@informatik.uni-erlangen.de (Toerless Eckert) Date: Sat, 3 Feb 96 13:29:54 CST Cc: rem-conf@es.net In-Reply-To: <199602030002.BAA28486@faui40.informatik.uni-erlangen.de>; from "Toerless Eckert" at Feb 3, 96 1:02 am X-Mailer: ELM [version 2.3 PL11] > > Another observation on my behalf with regards to buffering: > SS20/71 with SunVideo running SunOS 5.4: CIF size h261 compression > will max out at less than 20 frames per second, but the CPU is not > fully loaded. I know for sure that the rate at which the sunvideo > board can deliver uncompressed YUV (or RGB if that matters) CIF size > video is 25 for PAL and 30 for NTSC. Just wondering what is happening > here. Looks to me as if frames get lost between SunVideo and vic > probably because of not enough buffering. At least i excpet vic to > consume the CPU unless the maximum framerate of a grabber is achieved. > > Toerless > As regards SunVideo is concerned, does anybody know when we can have an SBus card to do hardware decompression? I wonder why Sun did not provide hardware decompression facility when the card exists to do compression. Thanks, -Ashfaq Hossain Dept of Computer Science, Univ of Illinois at Urbana-Champaign. From rem-conf-request@es.net Sat Feb 03 15:56:30 1996 Received: from alcor.concordia.ca by osi-west.es.net with ESnet SMTP (PP); Sat, 3 Feb 1996 12:55:53 -0800 Received: (from j_corte@localhost) by alcor.concordia.ca (8.6.12/8.6.12) id PAA10707; Sat, 3 Feb 1996 15:55:49 -0500 Date: Sat, 3 Feb 1996 15:55:49 -0500 (EST) From: Julio Cortez To: rem-conf@es.net Subject: Any multicast patches and kernel support for Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Linux, FreeBSD, and NetBSD yet? Are vat, vic, wb, and other mbone tools readily compilable on BSD and Linux? Or have some people already released binary versions for the various flavours of pc unix? Julio ps: Friends of mine have booked the mbone for the beginning of March for their Fashion Festival which they are hoping to broadcast live. Are there any people from Montreal interested in participating to make the connection and setup smoother? From rem-conf-request@es.net Sat Feb 03 16:30:31 1996 Received: from lestat.nas.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Sat, 3 Feb 1996 13:28:53 -0800 Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.7.3/8.6.12) with SMTP id NAA05990; Sat, 3 Feb 1996 13:26:25 -0800 (PST) Message-Id: <199602032126.NAA05990@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: Host localhost [127.0.0.1] didn't use HELO protocol To: Julio Cortez Cc: rem-conf@es.net Subject: Re: Any multicast patches and kernel support for Reply-To: Jason Thorpe From: Jason Thorpe Date: Sat, 03 Feb 1996 13:26:25 -0800 Sender: thorpej@nas.nasa.gov On Sat, 3 Feb 1996 15:55:49 -0500 (EST) Julio Cortez wrote: > Linux, FreeBSD, and NetBSD yet? > > Are vat, vic, wb, and other mbone tools readily compilable on BSD and Linux? > Or have some people already released binary versions for the various > flavours of pc unix? I've been using SunOS versions of the mbone tools under NetBSD/sparc for quite some time...One of these days, I'll get around to building native versions. Since NetBSD's audio interface is machine-independent (i.e. the same for all ports), once it works on the sparc, it should work on the PC and any other NetBSD system with audio capability. Vic compiled easily last time I tried. I haven't tried to compile wb yet. -------------------------------------------------------------------------- Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: 408.866.1912 NAS: M/S 258-6 Work: 415.604.0935 Moffett Field, CA 94035 Pager: 415.428.6939 From rem-conf-request@es.net Sat Feb 03 16:42:11 1996 Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Sat, 3 Feb 1996 13:41:19 -0800 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id WAA02339 (8.7.2/7.5a-FAU);; Sat, 3 Feb 1996 22:41:15 +0100 (MET) From: Toerless Eckert Message-Id: <199602032141.WAA02339@faui40.informatik.uni-erlangen.de> Subject: Re: SunVideo Hardware Decompression To: ashfaq@ipoint.vlsi.uiuc.edu (Ashfaq Hossain) Date: Sat, 3 Feb 1996 22:41:13 +0100 (MET) Cc: Toerless.Eckert@informatik.uni-erlangen.de, rem-conf@es.net In-Reply-To: <199602031929.NAA05295@berserk.ipoint.uiuc.edu> from "Ashfaq Hossain" at Feb 3, 96 01:29:54 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > As regards SunVideo is concerned, does anybody know when we can > have an SBus card to do hardware decompression? I wonder why > Sun did not provide hardware decompression facility when the > card exists to do compression. I think Sun won't go for such a board given that their VIS is deemed to deliver performance for exactly this application. I guess though, that there will be third party products to do this. From rem-conf-request@es.net Sat Feb 03 17:35:33 1996 Received: from alcor.concordia.ca by osi-west.es.net with ESnet SMTP (PP); Sat, 3 Feb 1996 14:34:26 -0800 Received: (from j_corte@localhost) by alcor.concordia.ca (8.6.12/8.6.12) id RAA22822; Sat, 3 Feb 1996 17:34:16 -0500 Date: Sat, 3 Feb 1996 17:34:15 -0500 (EST) From: Julio Cortez To: Jason Thorpe cc: rem-conf@es.net Subject: Re: Any multicast patches and kernel support for In-Reply-To: <199602032126.NAA05990@lestat.nas.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Anyone try to compile mbone tools on Linux for pc? Any problems/successes? Julio On Sat, 3 Feb 1996, Jason Thorpe wrote: > On Sat, 3 Feb 1996 15:55:49 -0500 (EST) > Julio Cortez wrote: > > > Linux, FreeBSD, and NetBSD yet? > > > > Are vat, vic, wb, and other mbone tools readily compilable on BSD and Linux? > > Or have some people already released binary versions for the various > > flavours of pc unix? > > I've been using SunOS versions of the mbone tools under NetBSD/sparc for > quite some time...One of these days, I'll get around to building native > versions. > > Since NetBSD's audio interface is machine-independent (i.e. the same for > all ports), once it works on the sparc, it should work on the PC and any > other NetBSD system with audio capability. > > Vic compiled easily last time I tried. I haven't tried to compile wb yet. > > -------------------------------------------------------------------------- > Jason R. Thorpe thorpej@nas.nasa.gov > NASA Ames Research Center Home: 408.866.1912 > NAS: M/S 258-6 Work: 415.604.0935 > Moffett Field, CA 94035 Pager: 415.428.6939 > From rem-conf-request@es.net Sat Feb 03 19:06:45 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Sat, 3 Feb 1996 16:05:43 -0800 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id QAA03156; Sat, 3 Feb 1996 16:04:57 -0800 Message-Id: <199602040004.QAA03156@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Jason Thorpe cc: Julio Cortez , rem-conf@es.net Subject: Re: Any multicast patches and kernel support for In-reply-to: Your message of "Sat, 03 Feb 1996 13:26:25 PST." <199602032126.NAA05990@lestat.nas.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 03 Feb 1996 16:04:56 -0800 From: "Amancio Hasty Jr." See http://rah.star-gate.com/~hasty/mbone.html for mbone tools available for FreeBSD. We have : vat-4.0a2 full duplex audio capability with the GUS PnP vic/nv video capture with the Matrox Meteor PCI video capture Soon to come will be support for the QuickCam wb/sd we just use the precompiled binaries for BSDI because the sources are not available. mbone vcr works fine on FreeBSD mrouted-3.8 is part of the FreeBSD release We also have a web page hooks for vat and nv Additionally, we have FreeBSD Lounge, an MBONE channel, in case that you want to talk to FreeBSD folks or just simply to check us out. A side note , we also have "tv" a cool program to display video. Currently, we have it working just like an X program however we have a version which dumps video frames from the matrox meteor PCI video capture board straight into the linear frame buffer of the PCI graphic card,i.e., PCI-TO-PCI video transfer. The effect is a smooth cool FreeBSD tv at 640*480*4 fps 8) Enjoy, Amancio >>> Jason Thorpe said: > On Sat, 3 Feb 1996 15:55:49 -0500 (EST) > Julio Cortez wrote: > > > Linux, FreeBSD, and NetBSD yet? > > > > Are vat, vic, wb, and other mbone tools readily compilable on BSD and Lin ux? > > Or have some people already released binary versions for the various > > flavours of pc unix? > > I've been using SunOS versions of the mbone tools under NetBSD/sparc for > quite some time...One of these days, I'll get around to building native > versions. > > Since NetBSD's audio interface is machine-independent (i.e. the same for > all ports), once it works on the sparc, it should work on the PC and any > other NetBSD system with audio capability. > > Vic compiled easily last time I tried. I haven't tried to compile wb yet. > > -------------------------------------------------------------------------- > Jason R. Thorpe thorpej@nas.nasa.gov > NASA Ames Research Center Home: 408.866.1912 > NAS: M/S 258-6 Work: 415.604.0935 > Moffett Field, CA 94035 Pager: 415.428.6939 From rem-conf-request@es.net Sat Feb 03 19:23:40 1996 Received: from shellx.best.com by osi-west.es.net with ESnet SMTP (PP); Sat, 3 Feb 1996 16:22:50 -0800 Received: from prince.vip.best.com (prince.vip.best.com [204.156.152.199]) by shellx.best.com (8.6.12/8.6.5) with SMTP id QAA19596; Sat, 3 Feb 1996 16:22:34 -0800 Message-Id: <199602040022.QAA19596@shellx.best.com> X-Sender: prince@pop.best.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 Feb 1996 15:00:35 -0400 To: Judy Estrin , Ross Finlayson From: vinay@mbone.com (Vinay Kumar) Subject: Re: RealAudio and RTP ? Cc: rem-conf@es.net, judy@precept.com, mccanne@ee.lbl.gov X-Mailer: Judy, At 05:03 PM 2/1/96 -0800, Judy Estrin wrote: > >2. We agree with your concerns about multiple proprietary approaches >fragmenting the industry. In fact we just announced our first products that >are based on RTP and are, we believe, the first commercially available >implementation for Windows based PC's. I believe it is just a matter of >time before you see broader industry acceptance and the Netscape endorsement >will help accelerate this. > Announcing RTP and TCP/IP stack products is great. We look forward to the products when shipped. Also, since we are on the subject of proprietary approaches fragmenting the Industry, i noticed that your company is selling another TCP/IP stack product with "optimizations built in for multimedia networking". This raised my curiosity a bit. What are these optimizations ? Are these optimizations part of vendor supported TCP/IP stacks such as Netmanage's Chameleon stack and FTP software's OnNet stack, MS Win95/NT stack etc...? If not, then are these optimizations Precept proprietary and how will they effect interoperability among different stacks in the market? Please pardon my ignorance if these optimizations are already publicly known and well-documented facts and part of IETF RFC's. >3. Steve Casner (who works here at Precept) wil look into your point about >an AVT session at the IETF meeting in LA and will respond seperately > If we are thinking about reviving the IETF AVT group, then we may also want to look at the broader impact of RTP. The RTP (draft 8.0) spec suggests that RTP is an application transport protocol for providing real-time services, and is not necessarily tied to either a media type such as audio and video, or to any specific application such as conferencing. Mention of RTP in the media, press and product announcements as an audio, video enabling protocol is a bit concerning. Steve McCanne and Van did an excellent job with SRM and are looking to redo "WB"'s application transport. If you look at SRM, then RTP is a great candidate for doing streaming of textual and graphical low bandwidth content over the MBone. RTP has all the right parameters (ala ALF) to support scalable reliable multicast delivery of text and graphics content if we marry some of SRM work from "WB". RTP coupled with low bandwidth applications such as reliable text/grpahics streaming over multicast would easily make MBone a household name. Scary thought, ain't it !?:) Use of RTP by itself for high bandwidth unicast audio, video streaming may have a different and not-so-pleasant effect on ISP's backbone bw use. My $0.02 worth of concerns and issues.... Regards --- Vinay Kumar vinay@mbone.com http://www.mbone.com/techinfo/ > > > >Judy Estrin >Precept Software, Inc. >21580 Stevens Creek Blvd., Suite 207 >Cupertino, CA 95014 >408 446-7600 > > From rem-conf-request@es.net Sat Feb 03 21:49:45 1996 Received: from shellx.best.com by osi-west.es.net with ESnet SMTP (PP); Sat, 3 Feb 1996 18:49:06 -0800 Received: from prince.vip.best.com (prince.vip.best.com [204.156.152.199]) by shellx.best.com (8.6.12/8.6.5) with SMTP id SAA05772; Sat, 3 Feb 1996 18:48:53 -0800 Message-Id: <199602040248.SAA05772@shellx.best.com> X-Sender: prince@pop.best.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 Feb 1996 17:26:56 -0400 To: Zhenjun Zhu , rem-conf@es.net From: vinay@mbone.com (Vinay Kumar) Subject: Re: Question regarding the RTP implementation. X-Mailer: Zhenjun, RTP is an application transport protocol that follows the principle of Application Level Framing (Clark and Tenenhouse, SIGCOMM 90). It is best to adapt RTP for each specific application and embed it inside the application itself. Building a generic stack that works for all scenarios, all applications, all media types and sub-types in my opinion is a tough problem. It may not be impossible problem to solve however. Regards --- Vinay Kumar vinay@mbone.com http://www.mbone.com/techinfo/ At 10:02 AM 2/1/96, Zhenjun Zhu wrote: > >I am wondering that for RTP what type of implementation would be the most >appropriate: > >[1] Simply integrated into application code design. > >[2] A single layer which provides applications with interfaces. > >[3] Interfaces implemented as system calls and code running in kernel. > >I velieve the different between [2] and [3] is whether to move the code >into Kernel or not. Between [1] and [2], would there be an differences in >terms of performance? > >Thanks. > >************************************************** >Zhenjun Zhu > >Graduate Student >Department of Computing and Information Science >Queen's University, Kingston, Canada > >zhuz@qucis.queensu.ca >************************************************** > > From rem-conf-request@es.net Sun Feb 04 01:26:02 1996 Received: from alcor.concordia.ca by osi-west.es.net with ESnet SMTP (PP); Sat, 3 Feb 1996 22:25:23 -0800 Received: (from j_corte@localhost) by alcor.concordia.ca (8.6.12/8.6.12) id BAA13191; Sun, 4 Feb 1996 01:25:21 -0500 Date: Sun, 4 Feb 1996 01:25:21 -0500 (EST) From: Julio Cortez To: rem-conf@es.net Subject: Mrouted-3.8 runs on Linux 1.2.13 for pc? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII (Thanks to the guys who responded to my previous questions.) Now, what framegrabbers are supported for nv, ivs, and vic for pc implementations? Which give the best price/performance ratio? Julio From rem-conf-request@es.net Sun Feb 04 04:01:55 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Sun, 4 Feb 1996 01:00:55 -0800 Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id BAA00990; Sun, 4 Feb 1996 01:00:25 -0800 Message-Id: <199602040900.BAA00990@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Julio Cortez cc: rem-conf@es.net Subject: Re: Mrouted-3.8 runs on Linux 1.2.13 for pc? In-reply-to: Your message of "Sun, 04 Feb 1996 01:25:21 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Feb 1996 01:00:22 -0800 From: "Amancio Hasty Jr." Don't know about linux. As for frame grabbers, it is kind of hard to beat the raw video performace of the matrox meteor pci video capture board. Currently, you need a triton or better chipset based motherboard because some PC motherboards can't cope with 36 MB/sec video stream in the PCI bus. If you are interested you can check out the specs for the meteor at: http://www.matrox.com/imgweb/meteor.htm Again, you will find that our FreeBSD driver couple with a "fast" PCI motherboard and the matrox meteor is more than adequate for vic,nv, or just plain old watching tv in your computer. The meteor sells for about $495. If you want the cheapest frame grabber / camera it is kind of hard to beat the QuickCam. It sells for less $90 and is a gray scale frame grabber/camera. Last but not least FreeBSD has had MBONE capability for over 2 years now. Amancio >>> Julio Cortez said: > (Thanks to the guys who responded to my previous questions.) > > Now, what framegrabbers are supported for nv, ivs, and vic for pc > implementations? Which give the best price/performance ratio? > > > Julio > > From rem-conf-request@es.net Sun Feb 04 07:52:08 1996 Received: from mailgate.aist-nara.ac.jp (actually fsb1.aist-nara.ac.jp) by osi-west.es.net with ESnet SMTP (PP); Sun, 4 Feb 1996 04:51:23 -0800 Received: from alpha503.aist-nara.ac.jp by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id VAA29536; Sun, 4 Feb 1996 21:51:15 +0900 Return-Path: Received: from localhost by alpha503.aist-nara.ac.jp (5.67+1.6W[kuis-17]/2.8Wb/NAIST-1.3[is]) id AA10762; Sun, 4 Feb 96 21:51:18 GMT+0900 Message-Id: <9602041251.AA10762@alpha503.aist-nara.ac.jp> To: "Amancio Hasty Jr." Cc: Julio Cortez , rem-conf@es.net Reply-To: oka@is.aist-nara.ac.jp Subject: Re: Mrouted-3.8 runs on Linux 1.2.13 for pc? In-Reply-To: Your message of Sun, 04 Feb 1996 01:00:22 PST. <199602040900.BAA00990@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain;charset="ISO-2022-JP" Date: Sun, 04 Feb 1996 21:51:17 +0900 From: Koji OKAMURA > Date: Sun, 04 Feb 1996 01:00:22 -0800 > From: "Amancio Hasty Jr." > If you want the cheapest frame grabber / camera it is kind of > hard to beat the QuickCam. It sells for less $90 and is a gray scale > frame grabber/camera. I am writing grabber-qcam.cc for linux using libqcam.a. Libqcam.a offers API of QuickCam for linux. You can get libqcam.a and its source from ftp://ftp.nas.com/laird/ And binary of vic from ftp://ftp.jain.ad.jp/pub/linux. -- Koji From rem-conf-request@es.net Sun Feb 04 10:39:41 1996 Received: from mailhost.lut.ac.uk (actually bgate.lut.ac.uk) by osi-west.es.net with ESnet SMTP (PP); Sun, 4 Feb 1996 07:38:35 -0800 Received: (jon@localhost) by weeble.lut.ac.uk (8.7.3/8.6.9) id PAA28470; Sun, 4 Feb 1996 15:37:51 GMT Date: Sun, 4 Feb 1996 15:37:46 +0000 (GMT) From: Jon Knight To: "Amancio Hasty Jr." cc: rem-conf@es.net Subject: Cheap framegrabbers In-Reply-To: <199602040900.BAA00990@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 4 Feb 1996, Amancio Hasty Jr. wrote: > If you want the cheapest frame grabber / camera it is kind of > hard to beat the QuickCam. It sells for less $90 and is a gray scale > frame grabber/camera. One thing I've wondered about from time to time is if anybody has got one of the QuickCam versions (either Mac or PC) to run on a Sun workstation. I would have thought that the Sun's I/O subsystem was more than beefy enough for it and it would be great for those of us that just want to send talking heads to MBONE sessions (and therefore not require a $1000 all-sing-all-dancing framegrabber Sbus card). Tatty bye, Jim'll -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. * From rem-conf-request@es.net Sun Feb 04 15:05:12 1996 Received: from nic.funet.fi by osi-west.es.net with ESnet SMTP (PP); Sun, 4 Feb 1996 12:04:16 -0800 Received: by nic.funet.fi id <5083-9558>; Sun, 4 Feb 1996 22:04:06 +0200 Subject: Re: Mrouted-3.8 runs on Linux 1.2.13 for pc? From: Matti Aarnio To: j_corte@alcor.concordia.ca (Julio Cortez) Date: Sun, 4 Feb 1996 22:04:04 +0200 (GMT) Cc: rem-conf@es.net In-Reply-To: from "Julio Cortez" at Feb 4, 96 01:25:21 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1397 Message-Id: <96Feb4.220406+0200_eet.5083-9558+49@nic.funet.fi> > (Thanks to the guys who responded to my previous questions.) > > Now, what framegrabbers are supported for nv, ivs, and vic for pc > implementations? Which give the best price/performance ratio? I wonder what the "Subject:" has to do with these questions.. Anyway, there are enough facilities for receiving multicast at the 1.2.13, however not all ethernet cards have full multicast support. I use ``bleeding edge'' kernels, and they have faster network facilities, and wider support for multicast at the network cards. There is also SOME support for multicast routeing in the most recent kernels, however it is not yet perfect. (The Linux networking software kernel parts have very little to do with any other implementation, the API is similar at the programmers level, but somewhat different at the libc..) A friend of mine added frame-grabber support for Creative Labs Video Blaster (some recent version), which is (for what I heard) fairly cheap ISA-bus grabber. After I had ported VIC-2.7a30 to Linux, she added frame-grabbing, and got about 2 fps (320x200?) out of it to H.261 stream with 486DX4-100. It turned out to be rather simple to add FG support to VIC, and if need turns up, propably also to NV and IVS.. Some existing tools are available at: ftp://ftp.funet.fi/pub/networking/services/multicast/LINUX/ > Julio /Matti Aarnio From rem-conf-request@es.net Mon Feb 05 00:07:30 1996 Received: from gw1.att.com by osi-west.es.net with ESnet SMTP (PP); Sun, 4 Feb 1996 21:06:46 -0800 Received: from arch4.ho.att.com by ig1.att.att.com id AA07657; Mon, 5 Feb 96 00:04:32 EST Received: from dahlia (dahlia.ho.att.com) by arch4.ho.att.com (4.1/EMS-1.2 GIS) id AA15475; Mon, 5 Feb 96 00:06:31 EST Received: by dahlia (4.1/EMS-1.1 SunOS) id AA06685; Mon, 5 Feb 96 00:08:34 EST Date: Mon, 5 Feb 96 00:08:34 EST From: shur@arch4.ho.att.com Message-Id: <9602050508.AA06685@dahlia> To: rem-conf@es.net Thanks to all who responded. Apparently there are a number of different ways that could improve matters ... A summary of the suggestions so far have included: 1)adding a socket call to greatly increase buffer sizes into the vic code. This should help reduce loss due to packet bursts when the receiver is not fully utilized. 2)traffic pacing on the sending side to smooth out traffic bursts 3)Using real-time scheduling (not 100% sure what this is yet) to give high priority to vic. 4) One comment was that vic allegedly gives priority to handling X events over reading incoming packets. The suggestion therefore was to change vic to give priority to reading packets over X events. 5) Another comment was that vic gives higher priority to outgoing data than to incoming. The suggestion was to use 2 separate instances of vic, one for sending, the other for receiving, with the sending instance with thumbnail size video. David. -------------------------------------------- Original message follows: Any advice, hints etc. for the following problem would be appreciated: We are running the usual suite of Mbone tools on SParc 20s with Solaris 2.4. (vic2.7a27, wb1.59, vat4.0a2). In vic, when transmitting and when we crank up the max bandwidth and max frame rate all the way (to approx 3 Mbps and 30 f/s resp.), we observe a high rate of UDP packet drops (20-30%) for received packets. The CPU does not appear to be maxed out while this is happening. We see the same behavior on a single dedicated ethernet subnet/segment (with nothing else running) and ATM SVCs (we use Fore 100 Mbps Taxi SBA200 adapters) within the same subnet. Also the behavior was basically the same with 32 Meg of Ram and 96 Meg of Ram. One theory is that the stream buffers are getting exhausted and hence UDP dumps the packets on the floor rather than sending them up (down) the stream. We have tried to find a kernel variable that might let us increase the number of stream buffers but have been unable to do so up to this point. We don't know if this behavior is application related or how the system can be more optimally tuned. or know of some other reason why this is happening. Thanks for your help. David. From rem-conf-request@es.net Mon Feb 05 01:26:31 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Sun, 4 Feb 1996 22:25:49 -0800 Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id WAA01927 for ; Sun, 4 Feb 1996 22:25:22 -0800 Message-Id: <199602050625.WAA01927@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: rem-conf@es.net Subject: http://www.cyber24.com/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Feb 1996 22:25:21 -0800 From: "Amancio Hasty Jr." Well, Cyberspace 24 is going to be using RealAudio . Any chance of them to use the mbone?? Tnks, Amancio From rem-conf-request@es.net Mon Feb 05 03:53:46 1996 Received: from alcor.concordia.ca by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 00:53:06 -0800 Received: (from j_corte@localhost) by alcor.concordia.ca (8.6.12/8.6.12) id DAA05481; Mon, 5 Feb 1996 03:53:04 -0500 Date: Mon, 5 Feb 1996 03:53:04 -0500 (EST) From: Julio Cortez To: rem-conf@es.net Subject: It seems that www.cilea.it is not responding. Anyone else having problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII accessing the mbone global agenda page? Julio From rem-conf-request@es.net Mon Feb 05 07:34:05 1996 Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 04:33:09 -0800 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id NAA03320 (8.7.2/7.5a-FAU);; Mon, 5 Feb 1996 13:32:19 +0100 (MET) From: Toerless Eckert Message-Id: <199602051232.NAA03320@faui40.informatik.uni-erlangen.de> Subject: Re: Cheap framegrabbers To: J.P.Knight@lut.ac.uk (Jon Knight) Date: Mon, 5 Feb 1996 13:32:19 +0100 (MET) Cc: hasty@rah.star-gate.com, rem-conf@es.net In-Reply-To: from "Jon Knight" at Feb 4, 96 03:37:46 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > One thing I've wondered about from time to time is if anybody has got one > of the QuickCam versions (either Mac or PC) to run on a Sun workstation. > I would have thought that the Sun's I/O subsystem was more than beefy > enough for it and it would be great for those of us that just want to > send talking heads to MBONE sessions (and therefore not require a $1000 > all-sing-all-dancing framegrabber Sbus card). As far as i can tell, there are two versions of the QuickCam. One for Apple, which uses a synchronuous serial interface with datarates comparable to localtalk (230 kbps). The other is for PC and uses the parallel interface port. For both versions of the camera, the interface protocol is roprietary, so before you buy one for the sun you should be sure to have software that knows how to talk to that biest. The quality isn't very good either. Toerless From rem-conf-request@es.net Mon Feb 05 08:06:50 1996 Received: from aohakobe.ipc.chiba-u.ac.jp by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 05:05:51 -0800 Received: from aohakobe (localhost [127.0.0.1]) by aohakobe.ipc.chiba-u.ac.jp (8.6.12/3.4Wbeta3 (-: 95041617) with ESMTP id WAA19348 for ; Mon, 5 Feb 1996 22:06:42 +0900 Message-Id: <199602051306.WAA19348@aohakobe.ipc.chiba-u.ac.jp> To: rem-conf@es.net Subject: Re: It seems that www.cilea.it is not responding. Anyone else having problems In-reply-to: Your message of "Mon, 05 Feb 1996 03:53:04 EST." Date: Mon, 05 Feb 1996 22:06:42 +0900 From: Yozo Toda (TELEPHONE +81-43-290-3539) > accessing the mbone global agenda page? there is another broadcast schedule page: I don't know if these pages try to synchronize the data. -- yozo. From rem-conf-request@es.net Mon Feb 05 09:04:38 1996 Received: from ceres.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 06:02:56 -0800 Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Mon, 5 Feb 1996 15:00:42 +0100 X-Mailer: exmh version 1.6.5 12/11/95 To: Toerless Eckert cc: J.P.Knight@lut.ac.uk (Jon Knight), hasty@rah.star-gate.com, rem-conf@es.net From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: Re: Cheap framegrabbers In-reply-to: Your message of "Mon, 05 Feb 1996 13:32:19 +0100." <199602051232.NAA03320@faui40.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Feb 1996 15:00:36 +0100 Sender: schulzrinne@fokus.gmd.de There apparently is a driver for FreeBSD. At least the /dev/bpp claims to support bidirectional I/O, so it may not even be necessary to write a kernel-level driver. Henning From rem-conf-request@es.net Mon Feb 05 09:43:06 1996 Received: from ns.metrolink.com by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 06:42:28 -0800 Received: from anubis.metrolink.com by ns.metrolink.com with SMTP id AA27076 (5.67b/IDA-1.5 for ); Mon, 5 Feb 1996 09:42:07 -0500 Received: by anubis.metrolink.com id AA05086 (4.1/SMI-4.1 for metrolink.com); Mon, 5 Feb 96 09:44:50 EST Date: Mon, 5 Feb 96 09:44:50 EST From: pax@anubis.metrolink.com (Garry M. Paxinos) Message-Id: <9602051444.AA05086@anubis.metrolink.com> To: Toerless Eckert Cc: ashfaq@ipoint.vlsi.uiuc.edu (Ashfaq Hossain), rem-conf@es.net Subject: Re: SunVideo Hardware Decompression In-Reply-To: <199602032141.WAA02339@faui40.informatik.uni-erlangen.de> References: <199602031929.NAA05295@berserk.ipoint.uiuc.edu> <199602032141.WAA02339@faui40.informatik.uni-erlangen.de> Toerless Eckert writes: > > As regards SunVideo is concerned, does anybody know when we can > > have an SBus card to do hardware decompression? I wonder why > > Sun did not provide hardware decompression facility when the > > card exists to do compression. > > I think Sun won't go for such a board given that their VIS is deemed > to deliver performance for exactly this application. I guess though, that > there will be third party products to do this. Parallax makes such a board... I have one here in my sparc... Visit: http://www.parallax.com for more details Take care, Pax. Metro Link Incorporated. 4711 N. Powerline Rd. Fort Lauderdale Fl, 33309 Voice: +1.954.938.0283x414 Fax: +1.954.938.1982 Email: pax@metrolink.com URL: http://www.flsig.org/people/garryp "The real voyage of discovery consists not in seeking new landscapes but in having new eyes." -Proust From rem-conf-request@es.net Mon Feb 05 09:49:18 1996 Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 06:48:33 -0800 Received: from delos (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with SMTP id PAA11335 (8.7.2/7.5a-FAU);; Mon, 5 Feb 1996 15:48:18 +0100 (MET) From: Toerless Eckert Message-Id: <199602051448.PAA11335@faui40.informatik.uni-erlangen.de> Subject: Re: SunVideo Hardware Decompression To: pax@anubis.metrolink.com (Garry M. Paxinos) Date: Mon, 5 Feb 1996 15:48:16 +0100 (MET) Cc: Toerless.Eckert@informatik.uni-erlangen.de, ashfaq@ipoint.vlsi.uiuc.edu, rem-conf@es.net In-Reply-To: <9602051444.AA05086@anubis.metrolink.com> from "Garry M. Paxinos" at Feb 5, 96 09:44:50 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > I think Sun won't go for such a board given that their VIS is deemed > > to deliver performance for exactly this application. I guess though, that > > there will be third party products to do this. > > Parallax makes such a board... I have one here in my sparc... Visit: > http://www.parallax.com for more details No comments. Ever used these boards ? From rem-conf-request@es.net Mon Feb 05 10:41:42 1996 Received: from cerc.wvu.edu (actually cathedral.cerc.wvu.edu) by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 07:39:47 -0800 Received: from elk (elk.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA21815; Mon, 5 Feb 96 10:39:39 EST Received: by elk (5.x//ident-1.0) id AA07687; Mon, 5 Feb 1996 10:39:30 -0500 Date: Mon, 5 Feb 1996 10:39:30 -0500 (EST) From: "Todd L. Montgomery" Subject: Re: RealAudio and RTP ? To: Vinay Kumar Cc: Judy Estrin , Ross Finlayson , rem-conf@es.net, judy@precept.com, mccanne@ee.lbl.gov In-Reply-To: <199602040022.QAA19596@shellx.best.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Vinay wrote: > >3. Steve Casner (who works here at Precept) wil look into your point about > >an AVT session at the IETF meeting in LA and will respond seperately > > > > If we are thinking about reviving the IETF AVT group, then we may also want > to look at the broader impact of RTP. The RTP (draft 8.0) spec suggests > that RTP is an application transport protocol for providing real-time > services, and is not necessarily tied to either a media type such as audio > and video, or to any specific application such as conferencing. Mention of > RTP in the media, press and product announcements as an audio, video > enabling protocol is a bit concerning. Steve McCanne and Van did an > excellent job with SRM and are looking to redo "WB"'s application transport. > If you look at SRM, then RTP is a great candidate for doing streaming of > textual and graphical low bandwidth content over the MBone. RTP has all the > right parameters (ala ALF) to support scalable reliable multicast delivery > of text and graphics content if we marry some of SRM work from "WB". RTP > coupled with low bandwidth applications such as reliable text/grpahics > streaming over multicast would easily make MBone a household name. Scary > thought, ain't it !?:) Use of RTP by itself for high bandwidth unicast > audio, video streaming may have a different and not-so-pleasant effect on > ISP's backbone bw use. Vinay has an excellent point. However, SRM and ALF lacks a basic feature in this context, IMO. That feature is message stability (or knowing when everyone has the message so you can collect its used memory). This is perfect for WB, where a history of all messages is actually part of the application. However, for data dissemination, this is a problem since keeping all messages at each sender and receiver is very costly in terms of memory. Also, a straight unicast ACK policy is undesirable since it has very bad network utilization (i.e. at best 25% at 250 receivers). ALF is a savior when it comes to efficiency, however, it still leaves the stability problem wide open. To this end, I am applying my work on RMP into some new directions. More info from: http://research.ivv.nasa.gov/projects/RMP/directions.html One of these directions is setting up an SRM (or NACK-based scheme) for RMP that will allow me to experiment and work on providing a fairly general framing architecture. ISIS and Horus both use a NACK-based scheme on the bottom and a basically a rotating token scheme running on that to provide stability. This is also the same approach RMP uses, however, we found a lot of performance gain by making the rotating token part of the lower layer. This approach is fine, but I think the answer for large scale reliable multicast really does lie in ALF somewhere. My desire is to make the framing architecture pluggable so that it can be taken out and some other mechanism used instead (something better tuned to the application). I intend to use some common design patterns to do this efficiently. Stability will also be done the same way. -- Todd Montgomery tmont@cerc.wvu.edu From rem-conf-request@es.net Mon Feb 05 11:15:45 1996 Received: from cismsun.univ-lyon1.fr by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 08:14:11 -0800 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id RAA13701; Mon, 5 Feb 1996 17:06:16 +0100 Message-Id: <199602051606.RAA13701@cismsun.univ-lyon1.fr> Subject: Re: UDP buffer overflows when using vic Mbone tool at high bandwidth To: shur@arch4.ho.att.com Date: Mon, 5 Feb 1996 17:06:15 +0100 (MET) From: Lucia Gradinariu Cc: rem-conf@es.net In-Reply-To: <9602021607.AA28337@dahlia> from "shur@arch4.ho.att.com" at Feb 2, 96 11:07:57 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 732 > > Any advice, hints etc. for the following problem would be appreciated: > > We are running the usual suite of Mbone tools on SParc 20s with Solaris > 2.4. (vic2.7a27, wb1.59, vat4.0a2). In vic, when transmitting and when > we crank up the max bandwidth and max frame rate all the way (to approx 3 > Mbps and 30 f/s resp.), we observe a high rate of UDP packet drops > (20-30%) for received packets. The CPU does not appear to be maxed out > while this is happening. > Then why this effect disappears when slowing down transmission (by reducing bw and/or #f/s)? I saw this some time ago between a SS20 and a SGI Indy but the loss was greater than 20-30% (rather 50-80% on videoconference on both stations ). Lucia Gradinariu From rem-conf-request@es.net Mon Feb 05 11:35:01 1996 Received: from jupiter.cs.uml.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 08:33:10 -0800 Received: from neptune.cs.uml.edu (neptune.cs.uml.edu [129.63.1.11]) by jupiter.cs.uml.edu (8.7.3/8.7.3) with ESMTP id LAA00709 for ; Mon, 5 Feb 1996 11:33:05 -0500 (EST) From: "John F. Buford" Received: (buford@localhost) by neptune.cs.uml.edu (8.6.11/8.6.9) id LAA01508 for rem-conf@es.net; Mon, 5 Feb 1996 11:33:04 -0500 Message-Id: <199602051633.LAA01508@neptune.cs.uml.edu> Subject: unsubscribe To: rem-conf@es.net Date: Mon, 5 Feb 1996 11:33:04 -0500 (EST) X-Mailer: ELM [version 2.4 PL22] Content-Type: text unsubscribe From rem-conf-request@es.net Mon Feb 05 14:50:19 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 11:49:32 -0800 Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id LAA02453; Mon, 5 Feb 1996 11:47:38 -0800 Message-Id: <199602051947.LAA02453@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Toerless Eckert cc: J.P.Knight@lut.ac.uk (Jon Knight), rem-conf@es.net Subject: Re: Cheap framegrabbers In-reply-to: Your message of "Mon, 05 Feb 1996 13:32:19 +0100." <199602051232.NAA03320@faui40.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Feb 1996 11:47:37 -0800 From: "Amancio Hasty Jr." >>> Toerless Eckert said: > > One thing I've wondered about from time to time is if anybody has got one > > of the QuickCam versions (either Mac or PC) to run on a Sun workstation. > > I would have thought that the Sun's I/O subsystem was more than beefy > > enough for it and it would be great for those of us that just want to > > send talking heads to MBONE sessions (and therefore not require a $1000 > > all-sing-all-dancing framegrabber Sbus card). > > As far as i can tell, there are two versions of the QuickCam. One for Apple, > which uses a synchronuous serial interface with datarates comparable to > localtalk (230 kbps). The other is for PC and uses the parallel interface po rt. > For both versions of the camera, the interface protocol is roprietary, so > before you buy one for the sun you should be sure to have software that know s > how to talk to that biest. The quality isn't very good either. > Well the FreeBSD and Linux camp are teaming up to provide a software solution for the QuickCam grayscale model. There several APIs floating around one of them is a library which anyone should be able to port to other Unix platforms if you are interested just send me mail and I will get you in touch with a few of the individuals working on the QuickCam API. The quality is not that great... Enjoy, Amancio From rem-conf-request@es.net Mon Feb 05 17:07:12 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 14:05:49 -0800 Received: from judy (aspen.precept.com) by precept.com (5.x/SMI-4.1) id AA23504; Mon, 5 Feb 1996 14:05:41 -0800 Date: Mon, 5 Feb 1996 14:05:41 -0800 Message-Id: <9602052205.AA23504@precept.com> X-Sender: judy@pophost.precept.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: vinay@mbone.com From: Judy Estrin Subject: Re: RealAudio and RTP ? Cc: rem-conf@es.net, finlayson@live.com, casner@precept.com Vinay, See my comments below.... > Also, since we are on the subject of proprietary approaches fragmenting >the Industry, i noticed that your company is selling another TCP/IP stack >product with "optimizations built in for multimedia >networking". This raised my curiosity a bit. What are these optimizations? >Are these optimizations part of vendor supported TCP/IP stacks such >as Netmanage's Chameleon stack and FTP software's OnNet stack, MS >Win95/NT >stack etc...? If not, then are these optimizations Precept proprietary and >how will they effect interoperability among different stacks in the market? >Please pardon my ignorance if these optimizations are already publicly >known and well-documented facts and part of IETF RFC's. I don't think this is the appropriate forum for going into product details, but in brief Precepts' FlashWare software runs on any standard Winsock protocol stack. We are also offering FlashStack for those that want to also buy a TCP/IP stack from the same source. It is a standard TCP/IP stack, the optimizations we have made are in the area of performance when running in a traffic intensive environment and do not include any protocol changes. If you have any further questions please feel free to contact me directly. Again, I will let steve casner respond to your point about the AVT working group. Judy Estrin Judy Estrin Precept Software, Inc. 21580 Stevens Creek Blvd., Suite 207 Cupertino, CA 95014 408 446-7600 From rem-conf-request@es.net Mon Feb 05 17:31:28 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 14:30:14 -0800 Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id OAA04011; Mon, 5 Feb 1996 14:29:41 -0800 Message-Id: <199602052229.OAA04011@rah.star-gate.com> To: Judy Estrin cc: rem-conf@es.net Subject: Re: RealAudio and RTP ? In-reply-to: Your message of "Mon, 05 Feb 1996 14:05:41 PST." <9602052205.AA23504@precept.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4008.823559380.1@rah.star-gate.com> Date: Mon, 05 Feb 1996 14:29:40 -0800 From: "Amancio Hasty Jr." >>> Judy Estrin said: > I don't think this is the appropriate forum for going into product details, > but in brief Precepts' FlashWare software runs on any standard Winsock Curious , what is the apropiate forum for discussing products such as yours? Hmmm... Is anyone of your staff on the mbone who would care to shed some light into your products ?? Amancio From rem-conf-request@es.net Mon Feb 05 19:18:52 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 16:17:56 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA23771; Mon, 5 Feb 1996 16:17:15 -0800 Date: Mon, 5 Feb 1996 16:17:14 -0800 (PST) From: Stephen Casner To: "Amancio Hasty Jr." Cc: Judy Estrin , rem-conf@es.net Subject: Re: RealAudio and RTP ? In-Reply-To: <199602052229.OAA04011@rah.star-gate.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Amancio, > >>> Judy Estrin said: > > I don't think this is the appropriate forum for going into product > > details, but in brief Precepts' FlashWare software runs on any > > Curious , what is the apropiate forum for discussing products such as yours? Well, I suppose it's fine for others to discuss our products on rem-conf and maybe even for us to answer questions about them, but we just wanted to observe proper netiquette and not engage in inappropriate product promotion on the list. > Hmmm... Is anyone of your staff on the mbone who would care to shed > some light into your products ?? What particular mode of "on the mbone" do you mean? We do tune in to mbone sessions now and then, though I don't have the luxury of being tuned into the MBone Audio session all the time as I did at ISI. Our sales staff would be happy to answer questions -- see www.precept.com. -- Steve From rem-conf-request@es.net Mon Feb 05 20:08:27 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 17:06:58 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA23842; Mon, 5 Feb 1996 17:06:49 -0800 Date: Mon, 5 Feb 1996 17:06:49 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: AVT session at Los Angeles IETF? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A couple of people have suggested the Audio/Video Transport working group should meet at the upcoming IETF meeting in Los Angeles. I'd be happy to chair a session there, and Allison Mankin says it is possible to fit an AVT session into the schedule. The question is: What shall we discuss? Lamenting the state of the world is not likely to be productive, but an AVT meeting could help in coordinating efforts to achieve interoperation among products if industry participants will be present. Or, we might establish new work that AVT or a new working group should be chartered to undertake. Ross Finlayson suggested: - Is RTP relevant? (I think so, at least I hope so. Netscape's announcement and adoption of RTP into ITU H.225.0 are positive votes.) The definite answer will only come with time. Is there an action item on this question? - Work on low-bandwidth and hierarchical encodings. That's a resonable suggestion, but development of encodings is not strictly IETF business. (In fact, when AVT was first chartered, there were explicit quidelines that the charter not include this area.) On the other hand, figuring out how to manage a collection of RTP sessions to carry a hierarchical encoding is relevant AVT business. (Michael Speer was working on some ideas on this topic a while back.) - Fostering interoperation among products through the use of RTP, perhaps with a conformance test and brand. In other protocol areas, I think this has been considered outside the scope of IETF itself. But we might discuss how some Interop-like interoperability test could be organized. Vinay Kumar suggested: - Extending RTP (e.g., defining profiles) for applications beyond audio and video. By name alone, this might be the charter of a new working group rather than AVT. I'd like to hear more from those who sent the recent suggestions and >from any others of you who would like to suggest topics, especially those who have something they would like to present. -- Steve From rem-conf-request@es.net Mon Feb 05 21:33:57 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 18:33:16 -0800 Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id SAA06162; Mon, 5 Feb 1996 18:32:41 -0800 Message-Id: <199602060232.SAA06162@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Stephen Casner cc: Judy Estrin , rem-conf@es.net Subject: Re: RealAudio and RTP ? In-reply-to: Your message of "Mon, 05 Feb 1996 16:17:14 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Feb 1996 18:32:41 -0800 From: "Amancio Hasty Jr." Hello Stephen, In this case lack of information is not cool net ettiguet. As for me, I have wb, sd, vic2.7a31 , vat working . Care to drop by tomorrow around 11:00 AM on FreeBSD Lounge thats because that channel is not heavily used and is used mostly for testing. If you are not compatible with vic2.7a31 h.261 let me know and I can try to get an older version of vic. Tnks and looking forward to hearing and seeing you guys 8) Amancio >>> Stephen Casner said: > Amancio, > > > >>> Judy Estrin said: > > > I don't think this is the appropriate forum for going into product > > > details, but in brief Precepts' FlashWare software runs on any > > > > Curious , what is the apropiate forum for discussing products such as your s? > > Well, I suppose it's fine for others to discuss our products on > rem-conf and maybe even for us to answer questions about them, but we > just wanted to observe proper netiquette and not engage in inappropriate > product promotion on the list. > > > Hmmm... Is anyone of your staff on the mbone who would care to shed > > some light into your products ?? > > What particular mode of "on the mbone" do you mean? We do tune in to > mbone sessions now and then, though I don't have the luxury of being > tuned into the MBone Audio session all the time as I did at ISI. > > Our sales staff would be happy to answer questions -- see > www.precept.com. > -- Steve From rem-conf-request@es.net Mon Feb 05 21:42:36 1996 Received: from shellx.best.com by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 18:41:42 -0800 Received: from prince.vip.best.com (prince.vip.best.com [204.156.152.199]) by shellx.best.com (8.6.12/8.6.5) with SMTP id SAA25845; Mon, 5 Feb 1996 18:40:49 -0800 Message-Id: <199602060240.SAA25845@shellx.best.com> X-Sender: prince@pop.best.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 05 Feb 1996 17:18:04 -0400 To: Judy Estrin From: vinay@mbone.com (Vinay Kumar) Subject: Re: RealAudio and RTP ? Cc: rem-conf@es.net, casner@precept.com X-Mailer: Judy, If you look back at my earlier posting, my question was the result of your concern for "multiple proprietary approaches fragmenting the Industry". My specific question related to a feature of your protocol stack product, namely the "optimizations". These "optimization" are claimed to be related to real-time multimedia networking, therefore the issue does relate to the agenda of the rem-conf list. Most of the real-time multimedia and protocol related issues have been discussed over the years on this list. And if your optimizations to TCP/IP protocol stack do effect the RTP developers and other TCP/IP stack vendors interms of interoperability (leading to fragmentation in the Industry), then people may want to discuss this over this forum. In anycase, since i did not get an ID# or an RFC# for the optimizations it maybe safe to assume now that these optimizations are proprietary. At 02:05 PM 2/5/96 -0800, Judy Estrin wrote: > >I don't think this is the appropriate forum for going into product details, >but in brief Precepts' FlashWare software runs on any standard Winsock >protocol stack. We are also offering FlashStack for those that want to also >buy a TCP/IP stack from the same source. It is a standard TCP/IP stack, the >optimizations we have made are in the area of performance when running in a >traffic intensive environment and do not include any protocol changes. This however means that the rtp applications will perform differently on different stacks that are available on the market. Regards --- Vinay Kumar vinay@mbone.com http://www.mbone.com/techinfo/ >If >you have any further questions please feel free to contact me directly. > >Again, I will let steve casner respond to your point about the AVT working >group. > >Judy Estrin > >Judy Estrin >Precept Software, Inc. >21580 Stevens Creek Blvd., Suite 207 >Cupertino, CA 95014 >408 446-7600 > > From rem-conf-request@es.net Mon Feb 05 21:46:19 1996 Received: from plateau.cs.Berkeley.EDU (actually bugs-bunny.CS.Berkeley.EDU) by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 18:45:43 -0800 Received: from garfield.CS.Berkeley.EDU (garfield.CS.Berkeley.EDU [128.32.32.118]) by plateau.cs.Berkeley.EDU (8.6.11/8.3) with ESMTP id SAA17992; Mon, 5 Feb 1996 18:38:11 -0800 Received: from garfield.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by garfield.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id SAA08602; Mon, 5 Feb 1996 18:40:55 -0800 Message-Id: <199602060240.SAA08602@garfield.CS.Berkeley.EDU> From: Andrew Swan To: 298@garfield.CS.Berkeley.EDU cc: rowe@cs.berkeley.edu Subject: Berkeley Multimedia Seminar 2/7/96 "The Microsoft Tiger Video Filesystem" X-URL: http://www.cs.berkeley.edu/~aswan/ Date: Mon, 05 Feb 1996 18:40:54 -0800 Sender: aswan@bugs-bunny.CS.Berkeley.EDU The third Berkeley Multimedia and Graphics seminar of the Spring 1996 semester will be held Wednesday, January 24 from 12:30 - 2:00 PST in 405 Soda Hall. The speaker will be Bill Bolosky of Microsoft Research, discussing "The Microsoft Tiger Video Fileserver" The talk will be broadcast on the Internet MBONE, beginning at roughly 12:40 PM PST. Please note that you will need vic 2.7 to watch the broadcast. Pre-compiled vic binaries for most architectures are available from: ftp://ftp.ee.lbl.gov/conferencing/vic/alpha-test/ We also hope to broadcast the seminar on the BAGNet -- an sd advertisement should appear by the time the seminar starts. Questions should be directed to Larry Rowe (rowe@cs.berkeley.edu) Abstract: The Microsoft Tiger video filesystem is a distributed, fault-tolerant filesystem that provides files at a constant, guaranteed bit rate (typically 2-6 MBits/s) to a potentially large (10,000+) number of clients. Tiger balances load by striping all of the files over all of the disks in the system, and introducing stream startup latency to avoid resource contention between different streams. Tiger is implemented on a collection of personal computers running Windows NT Server, connected by a switched network, typically an ATM network. In my talk, I will describe the basic architecture and fault tolerance design of the Tiger system, as well as presenting some performance measurements of personal computer IO systems. From rem-conf-request@es.net Mon Feb 05 23:32:29 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Feb 1996 20:31:31 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA24085; Mon, 5 Feb 1996 20:31:19 -0800 Date: Mon, 5 Feb 1996 20:31:18 -0800 (PST) From: Stephen Casner To: Zhenjun Zhu Cc: rem-conf@es.net Subject: Re: Question regarding the RTP implementation. In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Zhenjun Zhu: > I am wondering that for RTP what type of implementation would be the most > appropriate: > > [1] Simply integrated into application code design. > > [2] A single layer which provides applications with interfaces. > > [3] Interfaces implemented as system calls and code running in kernel. > > I velieve the different between [2] and [3] is whether to move the code > into Kernel or not. Between [1] and [2], would there be an differences in > terms of performance? I believe there is more difference between [2] and [3] than just moving code into the kernel. Making this move usually means the interface has to be fairly narrow. For example, I think that trying to implement RTP under the socket interface is probably not the right approach because of the constraints it would impose on function and performance. On the other hand, it's always more efficient to share and re-use code rather than creating from scratch each time. Over a class of applications, some parts of the RTP can be processed in a generic way and some parts must be application specific. So, the question is how to take advantage of the generic parts. Implementing RTP in a C++ library allows a wide interface of which an application can use as much or as little as is appropriate, and which can be customized through subclassing and overloading. There's also the opportunity to share objects on a larger granularity, sometimes called "middleware". For example, one such object might receive RTP-encapsulated video and display it in a window. That object can efficiently implement the parts of RTP specific to the video application. Then a higher level application that needed video could be built around this object. [To expose my bias, these two approaches are what we're doing at Precept.] -- Steve From rem-conf-request@es.net Tue Feb 06 04:00:12 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 00:59:33 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Feb 1996 08:58:55 +0000 To: Stephen Casner cc: Zhenjun Zhu , rem-conf@es.net Subject: Re: Question regarding the RTP implementation. In-reply-to: Your message of "Mon, 05 Feb 1996 20:31:18 PST." Date: Tue, 06 Feb 1996 08:58:52 +0000 Message-ID: <736.823597132@cs.ucl.ac.uk> From: Jon Crowcroft >Zhenjun Zhu: > >> I am wondering that for RTP what type of implementation would be the most >> appropriate: >> >> [1] Simply integrated into application code design. >> >> [2] A single layer which provides applications with interfaces. >> >> [3] Interfaces implemented as system calls and code running in kernel. >> >> I velieve the different between [2] and [3] is whether to move the code >> into Kernel or not. Between [1] and [2], would there be an differences in >> terms of performance? Steve Casner: >I believe there is more difference between [2] and [3] than just >moving code into the kernel. Making this move usually means the >interface has to be fairly narrow. For example, I think that trying >to implement RTP under the socket interface is probably not the right >approach because of the constraints it would impose on function and >performance. i believe that RTP frees us completely from the costly boundary (aka domain crossing by OS people) that is "kernel bound" and "user space" the model of packet filter/classifiers dealing with inbound packets right off the network interface strraight into user buffers is so much easier for RTP/UDP/IP/connectionless-link-layer, than it is when there is any complex "reliability" sematics like TCP's, which requires protocol lifetime longer than that of application process lifetime... then you can wrap up all the application specific packet re-ordering/playout buffer adaptation, RTCP based congestion avoidance, decompression/decoding/display loops at your leisure.... there is some reason to believe that ILP is not as wonderful an idea as all that, but the reduction of copies made possible by removing the packet/buffer ownership betwixt kernel and user is certainly a big win.... surely all RTP implementations right now are just simple shims....? cheers jon From rem-conf-request@es.net Tue Feb 06 04:05:32 1996 Received: from IMICILEA.CILEA.IT by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 01:04:44 -0800 Received: from uff29b.cilea.it by IMICILEA.CILEA.IT (IBM VM SMTP V2R2) with TCP; Tue, 06 Feb 96 10:02:10 MET X-Sender: guglielm@imicilea.cilea.it X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 06 Feb 1996 09:56:05 +0100 To: rem-conf@es.net From: Luciano Guglielmi Subject: Re: It seems that www.cilea.it is not responding. Anyone else having problems As webmaster@cilea.it I've no report of stop of my system...but all is possible..have any other ones the same problem? I've try to re-contact some times the person that managed the other MBone agenda for mirroring, and synchronise, our two tools...this mail for say: if you read this please send me a mail, and re-begin to work together.... Thanks, L. Guglielmi At 22.06 05/02/96 +0900, you wrote: > >> accessing the mbone global agenda page? > >there is another broadcast schedule page: > > >I don't know if these pages try to synchronize the data. > >-- yozo. > > ************************************************* * Luciano Guglielmi - CILEA (Milano) Italy * * tel: +39 2 26995.267 Fax: +39 2 2135520 * * e-mail: guglielmi@cilea.it, webmaster@cilea.it* * - coordinatore GARR-NIR - membro GCN * ************************************************* From rem-conf-request@es.net Tue Feb 06 04:24:55 1996 Received: from pepper.cs.ucdavis.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 01:23:55 -0800 Received: by pepper.cs.ucdavis.edu (4.1/UCD.CS.2.6) id AA18518; Tue, 6 Feb 96 01:19:00 PST Date: Tue, 6 Feb 96 01:19:00 PST From: infocom@cs.ucdavis.edu (Biswanath Mukherjee) Message-Id: <9602060919.AA18518@pepper.cs.ucdavis.edu> To: infocom@cs.ucdavis.edu Subject: Infocom96 Conference Program (We apologize if you are receiving multiple copies of this message since our mailing list is constructed from multiple different sources.) ========================================================================= Announcing... IEEE Infocom '96 ---- Networking the Next Generation ==================================================== Information about Infocom96, the Fifteenth Annual Joint Conference of the IEEE Computer and Communications Societies, is now available through the World Wide Web at http://www.research.att.com/~hgs/infocom96 Here are a few highlights: * Abstracts of all 176 accepted papers are now available on the web. * Conference Location: HOTEL NIKKO. SAN FRANCISCO, California, USA * Conference Dates: Tutorials: March 24-25, 1996 Conference: March 26-28, 1996 * Early (Discounted) Registration Deadline: February 23, 1996. * 44 Technical Sessions (in 4 parallel tracks), where 176 papers will be presented on the most recent advances in all aspects of networking, including multimedia, wireless, optical, multicasting, ATM, network management, queueing networks, network security, and system software. * Six tutorials by leading experts on the following topics: -- Wireless Communication Networks by Don Cox, Stanford University -- Image and Video Compression by Avideh Zakhor, UC Berkeley -- Optical Networking by Rajiv Ramaswami, IBM -- High-Speed Networks: From Ethernet to ATM by Pravin Varaiya, UC Berkeley -- Broadband Networking: Models and Techniques for Control, Design and Management by Debasis Mitra, AT&T Bell Laboratories -- Multimedia Conferencing over the Internet by Van Jacobson, LBL * Six panels on the challenges and promises of future networks: -- Wireless Multimedia Networks: Issues, Challenges and Directions -- Inter-operability in Multi-vendor ATM Networks -- How Much Synchronization is Needed for Multimedia Communication? -- Can High-Speed Wide-Area Networks be Effectively Controlled? -- Simulation Modeling of High Speed Networks: State of the Art and Challenges -- The Economics of the Internet * Keynote Speaker: Arno Penzias, AT&T Bell Laboratories * Plenary Session--Hamid Ahmadi, IBM, "Wireless and Mobile Networking - the Enterprise Perspective" * Hard copies of the Advance Program have been mailed to all IEEE Computer and Communications Society Members, as well as to all corresponding authors of Infocom96 submissions. For further information, please write to "infocom@cs.ucdavis.edu". Biswanath Mukherjee Technical Program Chair, IEEE INFOCOM '96 University of California Department of Computer Science Davis, California 95616, USA Email: infocom@cs.ucdavis.edu (for all correspondence re: Infocom '96) Telephone: +1-916-752-4826 Fax: +1-916-752-4767 From rem-conf-request@es.net Tue Feb 06 05:27:26 1996 Received: from relay7.UU.NET by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 02:26:40 -0800 Received: from iisc.ernet.in by relay7.UU.NET with SMTP id QQabsr00756; Tue, 6 Feb 1996 05:26:01 -0500 (EST) Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id AA06622; Tue, 6 Feb 96 16:01:26+0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA26509; Tue, 6 Feb 96 15:54:43+0530 From: anand@ece.iisc.ernet.in (SVR Anand) Message-Id: <9602061024.AA26509@ece.iisc.ernet.in> Subject: Re: Question regarding the RTP implementation. To: casner@precept.com (Stephen Casner) Date: Tue, 6 Feb 96 15:54:42 GMT+5:30 Cc: rem-conf@es.net In-Reply-To: ; from "Stephen Casner" at Feb 5, 96 8:31 pm X-Mailer: ELM [version 2.3 PL11] Stephen Casner, Implementing RTP in the kernel in the kernel has some benefits too. To begin with, the basic transport protocols are residing in the kernel. So, kernel has better knowledge about the dynamic behavior of the network than any user process. RTP cannot be too independent of the network parameters while deciding on say, how often control packets should be sent. Calculation of network jitter, and time related parameters can be more accrately done in the kernel. We are no longer bogged down by OS scheduling mechanism. If we write an application that makes use of the current network usage for determining the encoding scheme, and allow kernel to make the decision for us, then won't it be appropriate to have RTP there in kernel itself ? To put it conceptually, the application existing as a user process, is not expected to know the state of the network. For choosing the right parameters to support a service, the right candidate should be in kernel that has all the knowledge within the system and the network. If we put the decision maker in the kernel to make appropriate network demands, then we can let RTP logically, and otherwise reside beneath this module (decision maker). One of the functionalities of this module can be deciding on what encoding scheme should be used for that invocation of the application in mind. I hope I am atleast correct in parts, if not entirely :-) Regards Anand. From rem-conf-request@es.net Tue Feb 06 06:09:33 1996 Received: from faui45.informatik.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 03:08:07 -0800 Received: from faui01.informatik.uni-erlangen.de (root@faui01.informatik.uni-erlangen.de [131.188.2.1]) by uni-erlangen.de with ESMTP id MAA07537 (8.6.12/7.4f-FAU); for ; Tue, 6 Feb 1996 12:07:45 +0100 Received: from faui00g.informatik.uni-erlangen.de (mnfangme@faui00g.informatik.uni-erlangen.de [131.188.62.16]) by cip.informatik.uni-erlangen.de with ESMTP id MAA20913 (8.6.12/7.4h-FAU); for ; Tue, 6 Feb 1996 12:05:11 +0100 From: Martin Fangmeyer (CIP 90) Message-Id: <199602061105.MAA20913@faui01.informatik.uni-erlangen.de> Date: Tue, 6 Feb 1996 12:04:52 +0100 To: rem-conf@es.net Subject: subscribe subscribe From rem-conf-request@es.net Tue Feb 06 08:57:31 1996 Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 05:56:42 -0800 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id OAA23648 (8.7.2/7.5a-FAU);; Tue, 6 Feb 1996 14:56:12 +0100 (MET) From: Toerless Eckert Message-Id: <199602061356.OAA23648@faui40.informatik.uni-erlangen.de> Subject: Parallax JPEG software To: mbone@isi.edu, rem-conf@es.net Date: Tue, 6 Feb 1996 14:56:05 +0100 (MET) Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi If you are wondering what the Parallax boards can do in terms of performance for transmission of JPEG coded video, you may want to try MMSvideo, but don't expect it to be a video conferencing application. It's on ftp://ftp.informatik.uni-erlangen.de/pub/MMSvideo/MMSvideo-1.0.1.tar.gz Best regards Toerless An excerpt from the README: ... 1. WHAT IS MMSvideo ? MMSvideo is an application for Parallax video interface boards on Sun workstations to transmit JPEG compressed video over an IP network as good as possible. + Video: Up to 25 F/s of 768x576 (PAL) or 30 F/s of 640x480 (NTSC). + Protocols: TCP(unicast), UDP (unicast/multicast). ================================================================== - Status: MMSvideo is a TOY. It's not a real videoconferencing application. ================================================================== ... From rem-conf-request@es.net Tue Feb 06 09:12:06 1996 Received: from ns.metrolink.com by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 06:11:18 -0800 Received: from anubis.metrolink.com by ns.metrolink.com with SMTP id AA05581 (5.67b/IDA-1.5 for ); Tue, 6 Feb 1996 09:11:11 -0500 Received: by anubis.metrolink.com id AA09974 (4.1/SMI-4.1 for metrolink.com); Tue, 6 Feb 96 09:14:01 EST Date: Tue, 6 Feb 96 09:14:01 EST From: pax@anubis.metrolink.com (Garry M. Paxinos) Message-Id: <9602061414.AA09974@anubis.metrolink.com> To: vinay@prince.vip.best.com (Vinay Kumar) Cc: Judy Estrin , rem-conf@es.net, casner@hydra.precept.com Subject: Re: RealAudio and RTP ? In-Reply-To: <199602060240.SAA25845@shellx.best.com> References: <199602060240.SAA25845@shellx.best.com> Sorry for butting in on this... Vinay Kumar writes: > In anycase, since i did not get an ID# or an RFC# for the optimizations it > maybe safe to assume now that these optimizations are proprietary. >From what I read, there aren't any protocol changes so why would there be an RFC? > At 02:05 PM 2/5/96 -0800, Judy Estrin wrote: > >I don't think this is the appropriate forum for going into product details, > >but in brief Precepts' FlashWare software runs on any standard Winsock > >protocol stack. We are also offering FlashStack for those that want to also > >buy a TCP/IP stack from the same source. It is a standard TCP/IP stack, the > >optimizations we have made are in the area of performance when running in a > >traffic intensive environment and do not include any protocol changes. > This however means that the rtp applications will perform differently on > different stacks that are available on the market. That is the nature of the beast when it comes to commercial software. If you figure out some ways to make your implementation faster than the competition and yet remain protocol compatible you get more sales. So, if 'perform differently' translates to be better preformance on Precept's stack and is still protocol compatible, great. How do you think that an X server company like mine stays in business? Take care, Pax. Metro Link Incorporated. 4711 N. Powerline Rd. Fort Lauderdale Fl, 33309 Voice: +1.954.938.0283x414 Fax: +1.954.938.1982 Email: pax@metrolink.com URL: http://www.flsig.org/people/garryp "The real voyage of discovery consists not in seeking new landscapes but in having new eyes." -Proust From rem-conf-request@es.net Tue Feb 06 10:28:03 1996 Received: from qucis.queensu.ca by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 07:26:33 -0800 Received: from teaspoon.qucis.queensu.ca by qucis.queensu.ca (5.x/SMI-SVR4-qs1.6) id AA03249; Tue, 6 Feb 1996 10:26:16 -0500 Received: by teaspoon.qucis.queensu.ca (SMI-8.6/SMI-SVR4-qc1.3) id KAA20307; Tue, 6 Feb 1996 10:26:15 -0500 Date: Tue, 6 Feb 1996 10:26:14 -0500 (EST) From: Zhenjun Zhu X-Sender: zhuz@teaspoon To: rem-conf@es.net Subject: Further questions on RTP implementation Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Since I posted the question regarding the RTP implementations, most of the responses seem to lean towards implementation in user space rather than in the kernel. Now suppose the implementation is done in user space, if we would like to manage the RTP layer entities (say all the available sessions, mixers or translators, even participants) with agent-based management framework like SNMP, then the agent should be designed to extract information from applications. The tricky part is, if RTP is implemented in an OO fashion, and each application process constructs some instances of RTP objects (like session objects, user objects, etc.) then monitoring and management is a tedious and resource-intensive task. Anyone has more idea on this? Does it make sense to provide a single agent/daemon to manage RTP level entities? Apart from this issue, when the RTP MIB is defined, my view is that it can be divided down into sungroups for users, sessions, resources, mixers and translators. One thing I am not sure is: WHAT EXACTLY ARE THE RTP LEVEL RESOURCES? Thanks. - Zhenjun ************************************************** Zhenjun Zhu Graduate Student Department of Computing and Information Science Queen's University, Kingston, Canada zhuz@qucis.queensu.ca ************************************************** From rem-conf-request@es.net Tue Feb 06 11:16:06 1996 Received: from sirius.ctr.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 08:15:16 -0800 Received: from yosemite.ctr.columbia.edu (campbell@yosemite.ctr.columbia.edu [128.59.68.25]) by sirius.ctr.columbia.edu (8.7.2/8.6.4.287) with ESMTP id LAA09013; Tue, 6 Feb 1996 11:15:15 -0500 (EST) From: campbell@ctr.columbia.edu (Andrew T. Campbell) Received: (campbell@localhost) by yosemite.ctr.columbia.edu (8.7.2/8.6.4.788743) id LAA03777; Tue, 6 Feb 1996 11:15:07 -0500 (EST) Message-Id: <199602061615.LAA03777@yosemite.ctr.columbia.edu> Subject: Re: Question regarding the RTP implementation. To: casner@precept.com (Stephen Casner) Date: Tue, 6 Feb 1996 11:15:06 -0500 (EST) Cc: zhuz@qucis.queensu.ca, rem-conf@es.net In-Reply-To: from "Stephen Casner" at Feb 5, 96 08:31:18 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > On the other hand, it's always more efficient to share and re-use code > rather than creating from scratch each time. Over a class of > applications, some parts of the RTP can be processed in a generic way > and some parts must be application specific. So, the question is how > to take advantage of the generic parts. Implementing RTP in a C++ > library allows a wide interface of which an application can use as > much or as little as is appropriate, and which can be customized > through subclassing and overloading. On a related note: While I have been very impressed with the multimedia tools (vat, vic, etc) I have been concerned that each tool has to implement is own network/end-system conscious adaptation QoS mechanisms. Is there also an argument for abstracting out a set of QoS mechanisms and putting them and RTP under the hood too. With a QoS-based API AV applications could choose QoS management strategies >from a range of possibilities to suit each multimedia application. Why keep reinventing the wheel for each new tool ? Or is each one so different ? Andrew From rem-conf-request@es.net Tue Feb 06 11:30:17 1996 Received: from qucis.queensu.ca by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 08:29:41 -0800 Received: from teaspoon.qucis.queensu.ca by qucis.queensu.ca (5.x/SMI-SVR4-qs1.6) id AA04093; Tue, 6 Feb 1996 11:29:20 -0500 Received: by teaspoon.qucis.queensu.ca (SMI-8.6/SMI-SVR4-qc1.3) id LAA23505; Tue, 6 Feb 1996 11:29:18 -0500 Date: Tue, 6 Feb 1996 11:29:16 -0500 (EST) From: Zhenjun Zhu X-Sender: zhuz@teaspoon To: "Andrew T. Campbell" Cc: Stephen Casner , rem-conf@es.net Subject: Re: Question regarding the RTP implementation. In-Reply-To: <199602061615.LAA03777@yosemite.ctr.columbia.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Feb 1996, Andrew T. Campbell wrote: > On a related note: > > While I have been very impressed with the multimedia tools (vat, vic, etc) > I have been concerned that each tool has to implement is own > network/end-system conscious adaptation QoS mechanisms. Is there also > an argument for abstracting out a set of QoS mechanisms > and putting them and RTP under the hood too. This means there should be a mechanism allowing passing of QoS parameters >from top to bottom? I did consider a question before: Suppose ATM is the lower network layer, how do you specify in the RTP layer, which is on top of UDP/IP, the QoS parameters for the ATM layer? Conceptually, it makes sense to do that. Practically, I do not see UDP/IP provides any mechanism for the upper level to specify QoS. At least my experience with running applications over ATM is: you have to set up routing tables and ATMARP tabels at both ends before using some ATM OAM tool to set up a PVC -- this is where QoS is specified-- to tie two ends together. I have not seen operation of an application using SVC signalling (someone else must have seen) so I am not sure how QoS can be specified in such an application. By the way, does the research group led by Prof. Lazar in Columbia ever dealt with this problem? > AV applications could choose QoS management strategies > from a range of possibilities to suit each multimedia application. > Why keep reinventing the wheel for each new tool ? Or > is each one so different ? > > Andrew > > - Zhenjun ************************************************** Zhenjun Zhu Graduate Student Department of Computing and Information Science Queen's University, Kingston, Canada zhuz@qucis.queensu.ca ************************************************** From rem-conf-request@es.net Tue Feb 06 13:09:28 1996 Received: from apple.com by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 10:08:12 -0800 Received: from [38.10.180.129] (ip129.san-francisco.ca.interramp.com [38.10.180.129]) by apple.com (8.6.12/8.6.12) with SMTP id KAA27897 for ; Tue, 6 Feb 1996 10:08:04 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 Feb 1996 10:10:05 -0800 To: rem-conf@es.net From: markg@apple.com (Mark Green) Subject: MBONE announcement - Grammys Apple Computer would like to broadcast behind the scenes coverage of the Grammys on the MBONE. We will offer coverage that TV will not have such as interviews with nominees as well as coverage of the rehearsals and ceremony. The broadcast would take place on Wednesday, February 28 from about 2 PM to about 10 PM PST. We plan to broadcast using nv and vat with a ttl of 127. We realize that there is a shuttle mission running at this time and want to check on what constraints that will place on us in terms of bandwidth usage, etc. We would like to do this in cooperation with the MBONE community and plan to advertise the broadcast on sd and post it on www.cilea.it and www.msri.org. Please contact me if there are any questions or concerns about this broadcast. -------------------------------------------------------------------- Mark Green Apple Computer markg@apple.com Mail Stop 301-4H Wednesdays (408) 974-8099 One Infinite Loop Other days (510) 524-9654 Cupertino, CA 95014 From rem-conf-request@es.net Tue Feb 06 13:52:12 1996 Received: from cubo.ipn.uc.pt by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 10:51:05 -0800 Received: from mm1.ipn.uc.pt by cubo.ipn.uc.pt with SMTP (1.38.193.5/16.2) id AA02413; Tue, 6 Feb 1996 19:48:43 GMT Comments: Authenticated sender is From: Projecto VideoConferencia Organization: Projecto Videoconferencia To: campbell@ctr.columbia.edu, zhuz@qucis.queensu.ca, rem-conf@es.net Date: Thu, 7 Dec 1995 19:52:04 +0 Subject: Implementation RTP in C++ Return-Receipt-To: "Projecto VideoConferencia" Priority: urgent X-Mailer: Pegasus Mail for Windows (v2.23) > On the other hand, it's always more efficient to share and re-use > code rather than creating from scratch each time. Over a class of > applications, some parts of the RTP can be processed in a generic > way and some parts must be application specific. So, the question > is how to take advantage of the generic parts. Implementing RTP in > a C++ library allows a wide interface of which an application can > use as much or as little as is appropriate, and which can be > customized through subclassing and overloading. I'm a newbie in RTP protocol but I'm interested in knowing more about it. I'm particulary interested in knowing if there are any C++ librarys or API's implementing it? If there are how can i get them? Thanks in adavance. I'm looking forward your answer. From rem-conf-request@es.net Tue Feb 06 14:42:33 1996 Received: from inet1.tek.com by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 11:41:50 -0800 Received: by inet1.tek.com id ; Tue, 6 Feb 1996 11:41:41 -0800 From: rex.r.ferbrache@bangate1.tek.com Received: from bangate1.tek.com(128.181.153.52) by inet1 via smap (V1.3) id sma025581; Tue Feb 6 11:41:22 1996 Received: by bangate2.tek.com with VINES-ISMTP; Tue, 6 Feb 96 11:40:31 PST Date: Tue, 6 Feb 96 11:21:22 PST Message-Id: X-Priority: 3 (Normal) To: rem-conf Subject: Unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII unsubscribe From rem-conf-request@es.net Tue Feb 06 16:01:45 1996 Received: from gw2.att.com by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 13:00:39 -0800 Received: from buckaroo.ho.att.com by ig2.att.att.com id AA02713; Tue, 6 Feb 96 15:56:06 EST Received: from kin.buckaroo by buckaroo.ho.att.com (SMI-8.6/EMS-1.1 Sol2) id PAA29105; Tue, 6 Feb 1996 15:54:52 -0500 Received: by kin.buckaroo (5.x/SMI-SVR4) id AA05588; Tue, 6 Feb 1996 15:54:40 -0500 Date: Tue, 6 Feb 1996 15:54:40 -0500 Message-Id: <9602062054.AA05588@kin.buckaroo> From: kin@buckaroo.ho.att.com (Kin K Leung) To: Br Badrinath , ieeetcpc@ccvm.sunysb.edu, orcs-l%osuvm1.BITNET@searn.sunet.se, glynn@leland.stanford.edu, ietf-announce@cnri.reston.va.us, mobile-ip , f-troup@aurora.cis.upenn.edu, rem-conf-request@es.net, 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, arpanet-bboard@mc.lcs.mit.edu, cnom@meatro.bellcore.com, globecom@signet.com.sig, ietf@isi.edu, tccc@cs.umass.edu Subject: 2nd Call-JSAC mobile communications Content-Type: text Apology if you receive multiple copies of CFP. CALL FOR PAPERS IEEE Journal on Selected Areas in Communications NETWORKING AND PERFORMANCE ISSUES OF PERSONAL MOBILE COMMUNICATIONS In recent years, there has been a surge of interest in personal mobile communications systems and services, fueled by availability and exploitation of wireless spectrum, and the development of low-cost, low-power communications devices. Various types of such systems and services have been referred to as Personal Communications Networks (PCN), Personal Communications Services (PCS), Universal Personal Telecommunication (UPT), Universal Mobile Telecommunication System (UMTS), Future Public Land Mobile Telecommunication Systems (FPLMTS), etc. The development and deployment of these personal mobile communications systems raise significant technical issues at all protocol layers on these systems. There has been a tremendous amount of research and engineering work at the low-level protocols, aimed at meeting the challenges posed by the fundamental characteristics of personal mobile communications, namely user mobility, and the physical and link behavior and capacity of the wireless medium. However, these fundamental characteristics have significant impacts on the network and higher protocol layers. In particular, several challenges are raised for the wired infrastructure required to support personal mobile communications, in areas such as signaling, mobility and profile management, network databases, service software and architecture, teletraffic and performance, and network resource management, internetworking between wireless and wired networks, to name a few. The aim of this issue of J-SAC is to focus attention on the networking and performance issues posed by personal mobile communications at the network and higher protocol layers of the communications networks, and to also highlight solution approaches for the potential issues. Topics of interest include, but are not limited to the following: + Mobility management protocols and performance + Signaling network architectures, protocols, traffic and performance + Models of user mobility and characterization of mobility patterns + Tracking of user locations and performance tradeoffs + Network architectures for terminal, personal and service mobility + Network database algorithm, design, placement, performance, and reliability + Security and authentication protocols and their impacts on the wired infrastructure + Internetworking of wireless and wired Advanced Intelligent Networks (AIN) + Internetworking of wireless and ATM networks + Interworking of private (including radio LANs) and public wireless networks + Wired infrastructure and protocols to support wireless multimedia + Overload control design and performance of wireless and wired infrastructure for mobile communications + Architectures, protocols and network support for personal mobile information services + Personal mobile services and applications, including mobile computing + Billing and Operations Systems support Original, unpublished research articles will be considered. All articles will be evaluated according to a two-stage process as follows. Prospective authors are first invited to submit a summary of their paper to one of the Guest Editors listed below by April 1, 1996. Commitment notification is anticipated for June 1, 1996. If a summary is accepted, complete manuscript will be requested for submission by August 15, 1996 for full review. The anticipated publication date for this issue will be 2nd Quarter 1997. Hamid Ahmadi Ravi Jain IBM T J Watson Res Ctr Bellcore 30 Saw Mill Drive 445 South Street Hawthorne, NY 10532 Morristown, NJ 07960-6438 Tel: +1 914 784 7219 Tel: +1 201 829 4756 Fax: +1 914 784 7068 Fax: +1 201 829 5888 hamid@watson.ibm.com rjain@thumper.bellcore.com Paul J. Kuehn Kin K. Leung IND, Univ of Stuttgart AT&T Bell Laboratories Seidenstrasse 36 101 Crawfords Corner Road 70174 Stuttgart, Germany Holmdel, NJ 07733 Tel: +49 711 121 2479 Tel: +1 908 949 2061 Fax: +49 711 121 2477 Fax: +1 908 949 1720 kuehn@ind.uni-stuttgart.de kin.k.leung@att.com Victor O.K. Li Dept of Electrical Engineering Univ of Southern California Los Angeles, CA 90089-2565 Tel: +1 213 740 4665 Fax: +1 213 740 8729 vli@irving.usc.edu From rem-conf-request@es.net Tue Feb 06 16:08:33 1996 Received: from decu13.triumf.ca by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 13:07:39 -0800 Received: by decu13.triumf.ca (5.65/DEC-Ultrix/4.3) id AA08167; Tue, 6 Feb 1996 13:05:58 -0800 Date: Tue, 6 Feb 1996 13:05:46 -0800 (PST) From: Andrew Daviel To: rem-conf Distribution List Subject: HEPiX 96 on Mbone April 10-12 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We intend to broadcast the HEPiX 96 conference from Vancouver on April 10-12 1996. For information on the conference (Unix for High Energy Physics), see http://www.triumf.ca/hepix96/hepix.html We intend to use a ttl of 127. Tools are not decided at this point but will probably be vat/nv/wb. For questions relating to Mbone at TRIUMF, please contact Andrew Daviel . For questions relating to HEPiX 96, please contact Corrie Kost . Andrew Daviel email: advax@triumf.ca TRIUMF voice: 604-222-7376 4004 Wesbrook Mall fax: 604-222-7307 Vancouver BC http://andrew.triumf.ca/~andrew Canada V6T 2A3 49D14.7N 123D13.6W From rem-conf-request@es.net Tue Feb 06 17:09:36 1996 Received: from dragon.cc.ncsu.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 14:07:39 -0800 Received: by dragon.cc.ncsu.edu (8.6.9/UC06jan95) id RAA00892; Tue, 6 Feb 1996 17:07:36 -0500 From: paemer@unity.ncsu.edu Message-Id: <199602062207.RAA00892@dragon.cc.ncsu.edu> Subject: VAT misordered packets To: rem-conf@es.net Date: Tue, 6 Feb 1996 17:07:35 -0500 (EST) X-Mailer: ELM [version 2.4 PL24/POP] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 918 I just upgraded my mrouters to the prunig 3.8 version. I turned on a tunnel to myself and tried the ever faithful world radio network. I am dropping almost every packet due to misordering. The same is true for other VAT sessions except a one on one VAT - any idea what the deal is? I have a Sparc 5 with the usual gear and solaris 2.4 - it used to work. thanks, phil -- ======================================================================== Phillip Emer | 2620 Hillsborough St. Network Engineer | Box 7109 Research, Development and Data Communications | Raleigh, NC 27695 North Carolina State University | ------------------------------------------------------------------------ phil_emer@ncsu.edu 919-515-5491 http://www.cc.ncsu.edu/phil ======================================================================== From rem-conf-request@es.net Tue Feb 06 17:54:24 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 14:53:38 -0800 Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id OAA01415; Tue, 6 Feb 1996 14:52:30 -0800 Message-Id: <199602062252.OAA01415@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: markg@apple.com (Mark Green) cc: rem-conf@es.net Subject: Re: MBONE announcement - Grammys In-reply-to: Your message of "Tue, 06 Feb 1996 10:10:05 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Feb 1996 14:52:29 -0800 From: "Amancio Hasty Jr." >>> Mark Green said: > The broadcast would take place on Wednesday, February 28 from about 2 PM to > about 10 PM PST. We plan to broadcast using nv and vat with a ttl of 127. > Is it possible for you to broadcast using vic/h.261 as supposed to nv?? Tnks, Amancio From rem-conf-request@es.net Tue Feb 06 18:43:42 1996 Received: from plateau.cs.Berkeley.EDU (actually bugs-bunny.CS.Berkeley.EDU) by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 15:42:48 -0800 Received: from garfield.CS.Berkeley.EDU (garfield.CS.Berkeley.EDU [128.32.32.118]) by plateau.cs.Berkeley.EDU (8.6.11/8.3) with ESMTP id PAA21974; Tue, 6 Feb 1996 15:35:03 -0800 Received: from garfield.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by garfield.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id PAA11149; Tue, 6 Feb 1996 15:37:47 -0800 Message-Id: <199602062337.PAA11149@garfield.CS.Berkeley.EDU> From: Andrew Swan To: 298@bugs-bunny.CS.Berkeley.EDU Cc: rowe@cs.berkeley.edu Subject: Re: Berkeley Multimedia Seminar 2/7/96 "The Microsoft Tiger Video Filesystem" In-reply-to: Your message of "Mon, 05 Feb 1996 18:40:54 PST." <199602060240.SAA08602@garfield.CS.Berkeley.EDU> X-URL: http://www.cs.berkeley.edu/~aswan/ Date: Tue, 06 Feb 1996 15:37:46 -0800 Sender: aswan@bugs-bunny.CS.Berkeley.EDU I wrote: > The third Berkeley Multimedia and Graphics seminar of the Spring > 1996 semester will be held Wednesday, January 24 from 12:30 - 2:00 PST > in 405 Soda Hall. The speaker will be Bill Bolosky of Microsoft > Research, discussing "The Microsoft Tiger Video Fileserver" This seminar will actually be held tomorrow -- Wednesday, February 7th as indicated in the subject. Sorry about the typo. -Andrew From rem-conf-request@es.net Tue Feb 06 19:35:15 1996 Received: from agora.stm.it by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 16:34:30 -0800 Received: from netman.agora.stm.it (agora.stm.it [194.20.43.1]) by agora.stm.it (8.6.8.1/8.6.6) with SMTP id WAA07382 for ; Tue, 6 Feb 1996 22:54:19 GMT Date: Tue, 6 Feb 1996 22:54:19 GMT Message-Id: <199602062254.WAA07382@agora.stm.it> X-Sender: m.degregorio@hella.stm.it X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: Maurizio de Gregorio Subject: WEBCAST & LINUX I'm seeking WEBCAST (NCSA) for Linux. I found, in NCSA Ftp site, binaries for SUN and Irix only. Is there anyone who knows if they are available in other Ftp site, or if it is possible to have source codes? Thanks Maurizio __________________________________________________ Maurizio de Gregorio University of Florence Firenze (ITALY) Tel: +39-55-486530 e-mail: m.degregorio@agora.stm.it __________________________________________________ From rem-conf-request@es.net Tue Feb 06 20:24:09 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 16:00:38 -0800 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Feb 1996 23:59:00 +0000 To: Zhenjun Zhu cc: "Andrew T. Campbell" , Stephen Casner , rem-conf@es.net Subject: Re: Question regarding the RTP implementation. In-reply-to: Your message of "Tue, 06 Feb 1996 11:29:16 EST." Date: Tue, 06 Feb 1996 23:59:01 +0000 Message-ID: <13410.823651141@cs.ucl.ac.uk> From: Jon Crowcroft >> While I have been very impressed with the multimedia tools (vat, vic, etc) >> I have been concerned that each tool has to implement is own >> network/end-system conscious adaptation QoS mechanisms. Is there also >> an argument for abstracting out a set of QoS mechanisms >> and putting them and RTP under the hood too. maybe, just maybe, adapation is an application specific function (i.e. TCP works for elastic applications, ivs/wakeman/turletti scheme worksfine for ivs, while cu-seeme and vic have their own and vat and rat have thrir own audio specific schemes >This means there should be a mechanism allowing passing of QoS parameters >from top to bottom? maybe the mbone philosophy spells the end for specific QoS parameters - maybe, just maybe, you merely need to say 'bearer class X, where X is from a small set (size 2?) > >I did consider a question before: Suppose ATM is the lower network >layer, how do you specify in the RTP layer, which is on top of UDP/IP, >the QoS parameters for the ATM layer? Conceptually, it makes sense to do that. i cannot agree - atm is a phone companies replacement for SDH - it makes NO sense as an end to end global network service - the MTUs are all wrong, the multiplexing layer is wrong (and everyone is agreed that there should only be one multiplexing layer at any point in the network - so at an end system, it should be a globally identifiable item), rtp on atm makes no sense at all (despite the obvious attractios, it is in fact a snare and delusion - if you think VCI/VPI is the right id for a 'stream' then use it, and you don't need a synchronisation source, (i.e. the DAN philosohpy) otherwise use RTP+IP >Practically, I do not see UDP/IP provides any >mechanism for the upper level to specify QoS. At least my experience with >running applications over ATM is: you have to set up routing tables and >ATMARP tabels at both ends before using some ATM OAM tool to set up a PVC >-- this is where QoS is specified-- to tie two ends together. I have not >seen operation of an application using SVC signalling (someone else must >have seen) so I am not sure how QoS can be specified in such >an application. there is this thing called rsvp, which works just fine... >By the way, does the research group led by Prof. Lazar in Columbia ever >dealt with this problem? > >> AV applications could choose QoS management strategies >> from a range of possibilities to suit each multimedia application. >> Why keep reinventing the wheel for each new tool ? Or >> is each one so different ? yes, ISO got it wrong, layering is the wrong abstraction becuae there are no common layers except the internet layer, and it better not be VC based, as that wont work for multicast... to coin a phrase 'layered multicast multiplexing considered fatal' cheers jon From rem-conf-request@es.net Wed Feb 07 00:11:53 1996 Received: from sgi.sgi.com (actually SGI.COM) by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 21:11:13 -0800 Received: from cthulhu.engr.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for <@sgi.engr.sgi.com:rem-conf@es.net> id VAA29619; Tue, 6 Feb 1996 21:10:44 -0800 Received: from ganesh.engr.sgi.com by cthulhu.engr.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for <@sgi.engr.sgi.com:rem-conf@es.net> id QAA13658; Tue, 6 Feb 1996 16:01:53 -0800 Received: by ganesh.engr.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for rem-conf@es.net id QAA23158; Tue, 6 Feb 1996 16:01:53 -0800 Date: Tue, 6 Feb 1996 16:01:53 -0800 From: kamk@ganesh.engr.sgi.com (Kameran Kashani) Message-Id: <199602070001.QAA23158@ganesh.engr.sgi.com> To: rem-conf@es.net Subject: Announce: Net Show, Feb 8, 11:45PST The band Deth Specula would like to broadcast for approximately 45 minutes, beginning at 11:45am PST (7:45pm GMT) on February 8th. Technical contacts: Jon Luini (falcon@evolve.com) Eric Davis (ericd@internet.net) For more information about the show, see: http://www.deth.com/specula/ Thank you, Kameran Kashani Silicon Graphics Computer Systems From rem-conf-request@es.net Wed Feb 07 02:39:38 1996 Received: from ceres.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Feb 1996 23:38:37 -0800 Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Wed, 7 Feb 1996 08:36:18 +0100 X-Mailer: exmh version 1.6.5 12/11/95 To: Projecto VideoConferencia cc: campbell@ctr.columbia.edu, zhuz@qucis.queensu.ca, rem-conf@es.net From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: Re: Implementation RTP in C++ In-reply-to: Your message of "Thu, 07 Dec 1995 19:52:04." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Feb 1996 08:36:15 +0100 Sender: schulzrinne@fokus.gmd.de > I'm a newbie in RTP protocol but I'm interested in knowing more > about it. I'm particulary interested in knowing if there are any C++ > librarys or API's implementing it? If there are how can i get them? > > Thanks in adavance. > I'm looking forward your answer. The libraries that I'm aware of (one, plus, depending on your definition, the middleware by Precept) are listed in the RTP FAQ http://www.fokus.gmd.de/step/rtp. There is also a local (GMD Fokus) effort in constructing an RTP library (in C), but it's not quite ready yet. Some tools (such as NeVoT) can be used as a linkable library module, providing media-over-RTP rather than more generic RTP functionality. (Again, the Precept approach seems to be close to that. I'm sure Precept will correct me if I misinterpreted their architecture.) Henning > From rem-conf-request@es.net Wed Feb 07 05:52:45 1996 Received: from rsung.crn.cogs.susx.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 7 Feb 1996 02:52:05 -0800 Received: by rsung.crn.cogs.susx.ac.uk (Smail3.1.29.1 #3) id m0tk7To-00006kC; Wed, 7 Feb 96 10:52 GMT Message-Id: Date: Wed, 7 Feb 96 10:52 GMT From: ianw@cogs.susx.ac.uk (Ian Wakeman) To: campbell@ctr.columbia.edu (Andrew T. Campbell) cc: rem-conf@es.net Subject: Re: Question regarding the RTP implementation. In-Reply-To: <199602061615.LAA03777@yosemite.ctr.columbia.edu> References: <199602061615.LAA03777@yosemite.ctr.columbia.edu> >>>>> "Andrew" == Andrew T Campbell writes: Andrew> While I have been very impressed with the multimedia tools Andrew> (vat, vic, etc) I have been concerned that each tool has Andrew> to implement is own network/end-system conscious Andrew> adaptation QoS mechanisms. Is there also an argument for Andrew> abstracting out a set of QoS mechanisms and putting them Andrew> and RTP under the hood too. With a QoS-based API AV Andrew> applications could choose QoS management strategies from a Andrew> range of possibilities to suit each multimedia Andrew> application. Why keep reinventing the wheel for each new Andrew> tool ? Or is each one so different ? Coz each one is so different? Each interaction has to be source coding aware at the moment. Admittedly, one could specify a heirarchical marking scheme for a real-time stream (eg for MPEG video, mark at each I block, each B block and P block (could be the other way around), followed by each GoB etc), then specify precedence, priority and other QoS on those blocks to the local operating system, and synthesise a QoS end-system adaption policy based upon what the predicted behaviour will be, but that's tricky to optimise. Of course, if the network is aware and manipulates queues according to some QoS maintenance techniques, this can be factored into the calculation, but if we go for the heterogenous network approach where best effort over all traffic is the lowest common denominator, then the end system has to do all the work. If you believe we'll have a homogenous intelligent network, let the network do the work. If you don't, your end-systems have to be smart and optimise themselves. I belong in the latter camp, as you well know. I can't speak for anyone else. cheers ian From rem-conf-request@es.net Wed Feb 07 14:06:02 1996 Received: from fenris.hiof.no by osi-west.es.net with ESnet SMTP (PP); Wed, 7 Feb 1996 11:05:28 -0800 Received: from abdallah.hiof.no by fenris.hiof.no with SMTP (PP) id <28086-0@fenris.hiof.no>; Wed, 7 Feb 1996 20:05:21 +0100 Received: by abdallah.hiof.no (940816.SGI.8.6.9/940406.SGI.AUTO) id TAA11663; Wed, 7 Feb 1996 19:05:04 GMT Date: Wed, 7 Feb 1996 19:05:01 +0000 (GMT) From: Borre Ludvigsen To: rem-conf@es.net Subject: Audio pipe? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Somewhere (on a web page maybe), a short while ago, I saw an example command line that purported to pipe an audio stream from one Unix machine to another. Now I can't find it. Or to put it another way, how do I get vat running on one net to pipe its audio to an X-server on another? - Barre Borre Ludvigsen - http://www.hiof.no/~borrel finger: borrel@abdallah.hiof.no From rem-conf-request@es.net Wed Feb 07 16:33:39 1996 Received: from mail2.digital.com by osi-west.es.net with ESnet SMTP (PP); Wed, 7 Feb 1996 13:33:10 -0800 Received: from oreo.pa.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA07065; Wed, 7 Feb 1996 13:28:24 -0800 Received: by oreo.pa.dec.com; id AA23529; Wed, 7 Feb 96 13:28:24 -0800 Message-Id: <9602072128.AA23529@oreo.pa.dec.com> To: Borre Ludvigsen Cc: rem-conf@es.net, berc@pa.dec.com Subject: Re: Audio pipe? In-Reply-To: Your message of "Wed, 07 Feb 96 19:05:01 GMT." Date: Wed, 07 Feb 96 13:28:23 -0800 From: berc@pa.dec.com X-Mts: smtp If you use AudioFile (AF) then you point your AUDIOFILE environment variable at whatever server you want. If this makes no sense lookup up audiofile with altavista (www.altavista.digital.com). lance From rem-conf-request@es.net Thu Feb 08 04:12:40 1996 Received: from pimac2.iet.unipi.it by osi-west.es.net with ESnet SMTP (PP); Thu, 8 Feb 1996 01:11:35 -0800 Received: by pimac2.iet.unipi.it (5.57/Ultrix3.0-C) id AA17595; Thu, 8 Feb 96 10:11:27 +0100 Date: Thu, 8 Feb 96 10:11:27 +0100 Message-Id: <9602080911.AA17595@pimac2.iet.unipi.it> X-Sender: guargua@radar.iet.unipi.it X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: Giacomo Guarguaglini Subject: unsuscribe unsuscribe guargua@radar.iet.unipi.it Giacomo Guarguaglini ---------------------------------------------------------------------- X X X e-mail guargua@iet.unipi.it Giacomo Guarguaglini X X http://www_tlc.iet.unipi.it X X TEL. +39 50 568661 University of Pisa X X Department of X X Telecommunications and Information Engineering X X Networks Group Via Diotisalvi 2 X X 56126 PISA X X ITALY X ---------------------------------------------------------------------- From rem-conf-request@es.net Thu Feb 08 04:19:08 1996 Received: from nina.kolumbus.fi (actually pp.kolumbus.fi) by osi-west.es.net with ESnet SMTP (PP); Thu, 8 Feb 1996 01:18:31 -0800 Received: from marvin.hpy.fi (mail.hpy.fi [192.163.115.3]) by nina.kolumbus.fi (8.7.3/8.7.3) with SMTP id LAA23321 for ; Thu, 8 Feb 1996 11:14:42 +0200 (EET) Received: from rc.hpy.fi by marvin.hpy.fi (LAA06650); Thu, 8 Feb 1996 11:17:09 +0200 Received: by rc.hpy.fi (4.1/SMI-4.1) id AA23311; Thu, 8 Feb 96 11:00:56 +0200 Date: Thu, 8 Feb 1996 11:00:54 +0200 (EET) From: Markus B{ckstr|m To: rem-conf@es.net Subject: subscribe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Markus Backstrom Helsinki Telephone Company Ltd. (HPY) Research ================ tel: +358 0 606 4959, fax: +358 0 606 4545 email: Markus.Backstrom@hpy.fi From rem-conf-request@es.net Thu Feb 08 09:02:57 1996 Received: from cobra.gsfc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Thu, 8 Feb 1996 06:02:13 -0800 Received: by cobra.gsfc.nasa.gov; (5.65v3.2/1.1.8.2/03Jan96-1148AM) id AA04556; Thu, 8 Feb 1996 09:02:11 -0500 From: Gary Veum Message-Id: <9602081402.AA04556@cobra.gsfc.nasa.gov> Subject: wb on solaris 2.5? To: rem-conf@es.net Date: Thu, 8 Feb 1996 09:02:11 -0500 (EST) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 792 I apologize if this topic has been discussed, but I didn't know there was a problem until recently with it. On 2.5, wb works in readonly mode. When write access is enabled, it crashes with a seg fault. I've been told that these are running in compatibility mode (only sunos binaries are being distributed of wb). It appears as though the compatibility isn't quite as good in 2.5 as it was in 2.4. So, does someone have a wb that works on 2.5? If not, if provided with the source, we'd be happy to bundle it and provide it. thanks. -gv ------------------------------------------------------------------------------- Gary Veum Code 505 / Hughes/STX veum@cobra.gsfc.nasa.gov NASA Goddard Space Flight Center, PHONE 301-286-1073 Greenbelt MD 20771 FAX 301-286-0270 From rem-conf-request@es.net Thu Feb 08 09:20:11 1996 Received: from pelican.lannion.cnet.fr by osi-west.es.net with ESnet SMTP (PP); Thu, 8 Feb 1996 06:19:40 -0800 X400-Received: by /PRMD=cnet/ADMD=atlas/C=fr/; Relayed; 08 Feb 96 14:16:20+0100 Date: 08 Feb 96 14:16:20+0100 From: "Denis BIGORGNE - FT.CNET/LAA/TSS/RCP" Message-ID: <9602081316.AA16261@lsun258.lannion.cnet.fr> To: rem-conf-request@es.net Subject: unsuscribe cc: rem-conf@es.net unsuscribe bigorgne@lannion.cnet.fr Denis Bigorgne France Telecom - CNET/LAA/TSS/RCP BP 40 - 22301 LANNION CEDEX - FRANCE bigorgne@lannion.cnet.fr tph: (33) 96 05 26 31 fax: (33) 96 05 35 30 From rem-conf-request@es.net Thu Feb 08 09:51:00 1996 Received: from apollo.telecom.ipn.mx by osi-west.es.net with ESnet SMTP (PP); Thu, 8 Feb 1996 06:49:39 -0800 Received: by apollo.telecom.ipn.mx (1.38.193.5/16.2) id AA00762; Thu, 8 Feb 1996 08:48:32 -0600 Date: Thu, 8 Feb 1996 08:48:31 -0600 (Mexico) From: Eduardo Mendoza To: rem-conf@es.net Subject: suscribe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII please suscribe emendoza@apollo.telecom.ipn.mx From rem-conf-request@es.net Thu Feb 08 10:20:44 1996 Received: from cancer.ucs.ed.ac.uk by osi-west.es.net with ESnet SMTP (PP); Thu, 8 Feb 1996 07:20:17 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with ESMTP id PAA11206; Thu, 8 Feb 1996 15:18:19 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id PAA12456; Thu, 8 Feb 1996 15:20:18 GMT Date: Thu, 8 Feb 1996 15:20:18 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Gary Veum cc: rem-conf@es.net Subject: Re: wb on solaris 2.5? In-Reply-To: <9602081402.AA04556@cobra.gsfc.nasa.gov> Message-ID: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-URL: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 8 Feb 1996, Gary Veum wrote: > I apologize if this topic has been discussed, but I didn't know there > was a problem until recently with it. > > On 2.5, wb works in readonly mode. When write access is enabled, it crashes > with a seg fault. > > I've been told that these are running in compatibility mode (only sunos > binaries are being distributed of wb). It appears as though the compatibility > isn't quite as good in 2.5 as it was in 2.4. > > So, does someone have a wb that works on 2.5? > > If not, if provided with the source, we'd be happy to bundle it and provide > it. It works fine for me provided that I don't use Display PostScript to rasterize the PostScript. This never seemed to work very well on Solaris 2.4 either or on SGIs. I always force wb to use ghostscript. You can do this by setting the following X resource: wb.UseDPS: false ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Thu Feb 08 10:56:48 1996 Received: from sampson.cbn.org by osi-west.es.net with ESnet SMTP (PP); Thu, 8 Feb 1996 07:56:01 -0800 Received: by sampson.cbn.org; id KAA21145; Thu, 8 Feb 1996 10:56:22 -0500 From: "jack.legrand" Received: from u6.cbn.org(159.26.64.16) by sampson.cbn.org via smap (g3.0.3) id xma021143; Thu, 8 Feb 96 10:56:11 -0500 Received: from ccmail-gw.cbn.org by u6 (SMI-8.6/SMI-SVR4) id KAA00711; Thu, 8 Feb 1996 10:56:00 -0500 Received: from ccMail by ccmail-gw.cbn.org (SMTPLINK V2.10.08) id AA823805806; Thu, 08 Feb 96 10:53:48 EST Date: Thu, 08 Feb 96 10:53:48 EST Encoding: 8 Text Message-Id: <9601088238.AA823805806@ccmail-gw.cbn.org> To: rem-conf@es.net Subject: MBONE information I would like to receive information on MBONE. Thanks Jack LeGrand jackl@infi.net From rem-conf-request@es.net Thu Feb 08 19:21:14 1996 Received: from delirius (actually delirius.cs.uiuc.edu) by osi-west.es.net with ESnet SMTP (PP); Thu, 8 Feb 1996 16:20:36 -0800 Received: from glorius.srg by delirius (SMI-8.6/SMI-SVR4) id SAA11474; Thu, 8 Feb 1996 18:20:30 -0600 Received: by glorius.srg (SMI-8.6/SMI-SVR4) id SAA00613; Thu, 8 Feb 1996 18:20:29 -0600 Date: Thu, 8 Feb 1996 18:20:29 -0600 From: stan@delirius.cs.uiuc.edu (See-Mong Tan) Message-Id: <199602090020.SAA00613@glorius.srg> To: rem-conf@es.net Subject: Video Mosaic source and binary release ------------------------------------------------------------------------ Feb 9, 1996, Software Research Group, CS Dept., University of Illinois Vosaic integrates the organization, retrieval and navigation of continuous media into the World Wide Web. The Vosaic system includes a Web browser, server, and Video Datagram Protocol (VDP) that adapt to network load and client CPU conditions. Html extensions embed continuous or stored real-time video and audio in Web documents. The extensions may specify the starting and finishing frame of any clip of stored audio or video. Frame-based video annotations embed dynamic hyperlinks displayed as visible areas within the video data stream. Meta-information provides search capabilities for video databases. The newest B2.96 Release supports SGI and Sun (Solaris) browsers and SGI, Sun and HP servers. Users may create hypervideo documents using hyperlink editors and parse file generators included with the release. Although a variety of compression algorithms work with Vosaic, the current release supports MPEG-1 video and MPEG layer I or II sound. Software to create appropriate MPEG sources are available though links on the Vosaic Web site. Free binaries for Vosaic are available. Source is available at no charge to researchers and developers who agree to the terms of the Vosaic developer's licence. The Vosaic documentation and software is available from the Web site http://www.uiuc.edu/ph/www/vosaic. Two papers, one old and one new, describe the architecture. Browsers may view National Park and India footage as well as other demos at our site. Example Web course materials with embedded video being developed for a Multimedia and Operating System classes will also be available from time to time. Vosaic was developed by the Systems Research Group of the Department of Computer Science, University of Illinois at Urbana-Champaign. The Vosaic team includes Professor Roy Campbell, Zhigang Chen and See-Mong Tan of the University of Illinois, and Dong Xie of the University of Oslo, Norway. We welcome comments and feedback. E-mail may be addressed to vosaic@uiuc.edu. We hope you enjoy Vosaic. If you set up a video server, please let us know. From rem-conf-request@es.net Fri Feb 09 03:07:24 1996 Received: from pax.inria.fr by osi-west.es.net with ESnet SMTP (PP); Fri, 9 Feb 1996 00:06:05 -0800 Received: from [138.96.24.178] by pax.inria.fr (8.6.12/8.6.12) with SMTP id JAA11408; Fri, 9 Feb 1996 09:05:13 +0100 Date: Fri, 9 Feb 1996 09:05:13 +0100 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Zhenjun Zhu From: huitema@pax.inria.fr (Christian Huitema) Subject: Re: Further questions on RTP implementation Cc: rem-conf@es.net At 10:26 AM 6/2/96, Zhenjun Zhu wrote: >Since I posted the question regarding the RTP implementations, most of >the responses seem to lean towards implementation in user space rather >than in the kernel. > >Now suppose the implementation is done in user space, if we would like to >manage the RTP layer entities (say all the available sessions, mixers or >translators, even participants) with agent-based management framework >like SNMP, then the agent should be designed to extract information from >applications. RTP, or more precisely RTCP, allows "external monitoring". Your SNMP agent should just subscribe to the multicast group and listen to the RTCP port. It will get statistics on receiving rates, loss rates, jitter, propagation delays. Polling each receiver with SNMP just does not scale. Christian Huitema From rem-conf-request@es.net Fri Feb 09 04:58:50 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Fri, 9 Feb 1996 01:57:06 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 9 Feb 1996 09:55:52 +0000 To: Borre Ludvigsen cc: rem-conf@es.net Subject: Re: Audio pipe? In-reply-to: Your message of "Wed, 07 Feb 1996 19:05:01 GMT." Date: Fri, 09 Feb 1996 09:55:51 +0000 Message-ID: <795.823859751@cs.ucl.ac.uk> From: Jon Crowcroft >Somewhere (on a web page maybe), a short while ago, I saw an example >command line that purported to pipe an audio stream from one Unix machine >to another. Now I can't find it. Or to put it another way, how do I get >vat running on one net to pipe its audio to an X-server on another? Barre the answer to the first part is that you can make a very good etherphone by running cat /dev/audio albeit with a somewhat large (TCP and sh buffer) delay the answer to the second part is, "it depends on the X server..." jon From rem-conf-request@es.net Fri Feb 09 07:17:42 1996 Received: from basil.cdt.luth.se by osi-west.es.net with ESnet SMTP (PP); Fri, 9 Feb 1996 04:16:16 -0800 Received: from kalkyl.cdt.luth.se (kalkyl.cdt.luth.se [130.240.193.31]) by basil.cdt.luth.se (8.6.12/8.6.12) with ESMTP id NAA11860; Fri, 9 Feb 1996 13:15:40 +0100 Received: from kalkyl (localhost [127.0.0.1]) by kalkyl.cdt.luth.se (8.6.12/8.6.12) with ESMTP id NAA29517; Fri, 9 Feb 1996 13:16:35 +0100 Message-Id: <199602091216.NAA29517@kalkyl.cdt.luth.se> X-Mailer: exmh version 1.6.4 10/10/95 To: Graeme.Wood@ucs.ed.ac.uk cc: Gary Veum , rem-conf@es.net Subject: Re: wb on solaris 2.5? In-reply-to: Your message of "Thu, 08 Feb 1996 15:20:18 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 09 Feb 1996 13:16:35 +0100 From: Peter Parnes jaw@ucs.ed.ac.uk said: > It works fine for me provided that I don't use Display PostScript to = > rasterize the PostScript. This never seemed to work very well on = > Solaris 2.4 either or on SGIs. I always force wb to use ghostscript. = > You can do this by setting the following X resource: > wb.UseDPS: false = I'm have been using Wb with DPS under Sol2.4 and 2.5 for some time now. T= here were some DPS problems under 2.4/XSun that were fixed by some Solari= s-patch (if it's important I find out which one it is) but besides that i= t works fine under 2.4/2.5. /P From rem-conf-request@es.net Fri Feb 09 08:04:43 1996 Received: from teco01a.teco.uni-karlsruhe.de by osi-west.es.net with ESnet SMTP (PP); Fri, 9 Feb 1996 05:03:48 -0800 Received: from teco03a.teco.uni-karlsruhe.de by teco01a.teco.uni-karlsruhe.de (8.6.12) id OAA30326; Fri, 9 Feb 1996 14:02:11 +0100 Full-Name: Eckhard Farrenkopf Received: by teco03a.teco.uni-karlsruhe.de (8.6.12) id OAA01021; Fri, 9 Feb 1996 14:02:04 +0100 Date: Fri, 9 Feb 1996 14:02:04 +0100 Message-Id: <199602091302.OAA01021@teco03a.teco.uni-karlsruhe.de> From: Eckhard Farrenkopf To: rem-conf@es.net cc: mbone@teco.uni-karlsruhe.de Subject: Bill Gates lecture today at 16:30 MET Reply-To: mbone@teco.uni-karlsruhe.de William H. Gates - Chief Executive Officer of Microsoft - is on a visit to Karlsruhe, Germany. During his visit, he gives a talk at the University of Karlsruhe. The subject of Gates lecture will be: Microsoft's Internet Strategy The event is scheduled on February, 9th 16:30 MET. We thought this might be of public interest for the internet family and transmit this lecture on Mbone. Additional information see sd or http://www.teco.uni-karlsruhe.de/gates/ Comments and contradictions to mbone@teco.uni-karlsruhe.de From rem-conf-request@es.net Fri Feb 09 08:49:36 1996 Received: from cobra.gsfc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Fri, 9 Feb 1996 05:49:00 -0800 Received: by cobra.gsfc.nasa.gov; (5.65v3.2/1.1.8.2/03Jan96-1148AM) id AA10726; Fri, 9 Feb 1996 08:48:22 -0500 From: Gary Veum Message-Id: <9602091348.AA10726@cobra.gsfc.nasa.gov> Subject: Re: wb on solaris 2.5? To: peppar@cdt.luth.se (Peter Parnes) Date: Fri, 9 Feb 1996 08:48:21 -0500 (EST) Cc: rem-conf@es.net In-Reply-To: <199602091216.NAA29517@kalkyl.cdt.luth.se> from "Peter Parnes" at Feb 9, 96 01:16:35 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1125 Excerpts from Peter Parnes's mail: ] ] jaw@ucs.ed.ac.uk said: ] > It works fine for me provided that I don't use Display PostScript to = ] ] > rasterize the PostScript. This never seemed to work very well on = ] ] > Solaris 2.4 either or on SGIs. I always force wb to use ghostscript. = ] ] > You can do this by setting the following X resource: ] > wb.UseDPS: false = ] ] ] I'm have been using Wb with DPS under Sol2.4 and 2.5 for some time now. T= ] here were some DPS problems under 2.4/XSun that were fixed by some Solari= ] s-patch (if it's important I find out which one it is) but besides that i= ] t works fine under 2.4/2.5. peter, we discovered we need to fine tune the question. is anyone using wb on solaris 2.5 with a SX framebuffer? Graeme was using on a b/w system. we've tried on with and w/o using CDE and other window managers. thanks. -gv ------------------------------------------------------------------------------- Gary Veum Code 505 / Hughes/STX veum@cobra.gsfc.nasa.gov NASA Goddard Space Flight Center, PHONE 301-286-1073 Greenbelt MD 20771 FAX 301-286-0270 From rem-conf-request@es.net Fri Feb 09 13:48:04 1996 Received: from agate.lut.ac.uk by osi-west.es.net with ESnet SMTP (PP); Fri, 9 Feb 1996 08:01:23 -0800 Received: (jon@localhost) by weeble.lut.ac.uk (8.7.3/8.6.9) id PAA21139; Fri, 9 Feb 1996 15:59:41 GMT Date: Fri, 9 Feb 1996 15:59:40 +0000 (GMT) From: Jon Knight To: mbone@teco.uni-karlsruhe.de cc: rem-conf@es.net Subject: Re: Bill Gates lecture today at 16:30 MET In-Reply-To: <199602091302.OAA01021@teco03a.teco.uni-karlsruhe.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 9 Feb 1996, Eckhard Farrenkopf wrote: > The subject of Gates lecture will be: > > Microsoft's Internet Strategy Wow, I didn't realise that they'd got a strategy. I thought they were still reeling from the shock of finding all these people on the Internet not using Microsoft products... :-) :-) Tatty bye, Jim'll -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. * From rem-conf-request@es.net Fri Feb 09 19:39:01 1996 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Fri, 9 Feb 1996 16:38:25 -0800 Received: from relay.jf.intel.com (root@relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.6.12/8.6.12) with SMTP id QAA13732; Fri, 9 Feb 1996 16:38:11 -0800 Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.29.1 #4) id m0tl3KM-000HzJC; Fri, 9 Feb 96 16:38 PST Original-Received: by ccm.jf.intel.com (ccmgate 3.2 #4) Fri, 09 Feb 96 16:38:10 PST PP-warning: Illegal Received field on preceding line Date: Fri, 09 Feb 96 16:35:00 PST From: Jim Toga Message-ID: To: internet-drafts@cnri.reston.va.us, rem-conf@es.net, huitema@sophia.inria.fr, turletti@sophia.inria.fr Subject: Text item: Colleagues, Enclosed/attached is a draft describing the RTP payload format for H.263 Video Stream. Regards, Jim Toga ************************************************************************* *** voice: 503.264.8816(w) 503.264.3485(fax) *** *** email: jim_toga@ccm.jf.intel.com *** *** Intel - Hillsboro, OR. *** ************************************************************************* Text item: rtp263.txt 2/9/96 2:00P Internet Engineering Task Force Audio-Video Transport WG INTERNET-DRAFT Chunrong "Chad" Zhu Intel Corp. February 8, 1996 Expires: 8/8/96 RTP Payload Format for H.263 Video Stream 1. Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of 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 maybe updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "lid-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 Cost). Distribution of this document is unlimited. 2. Abstract and Document Scope This document describes a scheme to packetize an H.263 video stream for transport using Real-Time Transport Protocol (RTP) [1]. H.263 video stream is defined by ITU-T Recommendation H.263 (referred to as H.263 in this document) [4] for video coding at very low bit rate. RTP is defined by the Internet Engineering Task Force (IETF) to provide end-to-end network transport functions suitable for applications transmitting real-time data over multicast or unicast network services. 3. Introduction This document specifies the RTP payload format for encapsulating H.263 bitstreams in RTP. The H.263 payload header is designed for flexibility and simplicity. RTP can use one of three possible modes for H.263 video streams depending on the desired performance characteristics. The shortest header mode (Mode A) results in simplicity and easy recovery of lost packets, brought about by fragmentation at Group of Block (GOB) boundaries. The long header modes (Mode B and C) result in more efficient use of bandwidth, brought about by fragmentation at Macroblock (MB) boundaries. The complete specification of RTP for a particular application will require a profile specification document [3], a payload format specification, and an RTP protocol document [1]. This document is intended to serve as the payload format specification for H.263 video streams. 4. Definitions For the purpose of this document, the following definitions apply: CIF: Common Intermediate Format. For H.263, a CIF picture has 352 x 288 pixels for luminance, and 176 x 144 pixels for chrominance. QCIF: Quarter CIF source format with 176 x 144 pixels for luminance and 88 x 72 pixels for chrominance. sub-QCIF: picture source format with 128 x 96 pixels for luminance and 64 x 48 pixels for chrominance. 4CIF: picture source format with 704 x 576 pixels for luminance and 352 x 288 pixels for chrominance. 16CIF: picture source format with 1408 x 1152 pixels for luminance and 704 x 288 pixels for chominance. GOB: for H.263, a Group of Blocks (GOB) comprises of k*16 lines, depending on the picture format (k=1 for QCIF, CIF and sub-QCIF, k=2 for 4CIF and k=3 for 16CIF). MB: a macroblock (MB) relates to four blocks of luminance and the spatially corresponding two blocks of chrominance. Each block consists of 8x8 pixels. 5. Design Issues for Packetizing H.263 Bitstream H.263 is based on ITU-T Recommendation H.261 [2] (referred to as H.261 in this document). Although it employs similar techniques to reduce both temporal and spatial redundancy, there are several major differences between the two algorithms that impact the design of packetization schemes significantly. This section summarizes those differences. 5.1 Optional Features of H.263 In addition to the basic source coding algorithms, H.263 supports four negotiable features to improve performance: Advanced Prediction, PB frames, Syntax-based Arithmetic Coding, and Unrestricted Motion Vectors. They can be used in any combination. These optional features make session management a little harder to handle. Advanced Prediction(AP): four motion vectors instead of one can be used for some macroblocks in the frame. This feature makes recovery from packet loss harder, because more redundant information has to be preserved at the beginning of the packet when fragmenting at macroblock boundaries. PB frames: two frames ( P frame and B frame) are coded into one bitstream with macroblocks from two frames interleaved. From packetization point of view, a MB from the P frame and a MB from the B frame must be treated together because each MB for the B frame are coded based on the corresponding MB for the P frame. Means must be provided to ensure proper rendering of two frames in the right order. Also if part of this combined bitstream is lost, it will impact the two frames, and possibly more. Syntax-based Arithmetic Coding (SAC): Huffman codes are not the only choice for variable length coding. When SAC option is on, the run value pair resulted after quantization of Discrete Cosine Transform (DCT) coefficients will be coded differently from Huffman codes, but macroblock hierarchy will be preserved. Unrestricted motion vector feature does not impact packetization directly. No special treatment is needed. 5.2 GOB Numbering In H.263, each picture is divided into groups of blocks (GOB). GOBs are numbered by vertical scan of the GOBs, starting with the upper GOB and ending with the lower GOB. In contrast, a GOB in H.261 is composed of three rows of 16x16 MB for all QCIF, and three half rows of MB for CIF format. Like H.261, a GOB is divided into macroblocks. The definition of a macroblock is the same as in H.261. Each GOB in H.263 can have a fixed GOB header, but unlike H.261 the use of the header is optional. If the GOB header is present, it may or may not start on a byte boundary. Byte alignment can be achieved by proper bit stuffing by the encoder, but it is not required. In summary, a GOB in H.263 is defined and coded with finer granularity with the same source format, thus resulting in more flexibility for packetization than H.261. 5.3 Motion Vectors Encoding Differential coding is used to code motion vectors as variable length codes. Unlike in H.261, where each motion vector is predicted from the previous MB in the GOB, H.263 employs a more flexible prediction scheme, where three candidate predictors are used instead of one. It is done differently depending on the presence of GOB header. If the GOB header is included for a GOB, motion vectors are coded with reference to MBs in this GOB only. But if GOB header is not present for the current GOB, three motion vectors must be available to decode one macroblock, where two of them are from the previous GOB. To decode the whole inter-coded GOB, all the motion vectors must be available from the previous GOB. This can be a major problem for a packetization scheme like the one defined for H.261 when packetizing at MB boundary. Assume a packet starts with one MB but the GOB header is not coded. If the previous packet is lost, then all the motion vectors to predict the motion vector for the MBs in this GOB are not available. In order to decode the received MBs correctly, all the motion vectors for the previous GOB would have to be saved at the beginning of the packet. This would be very expensive in terms of bandwidth. We address these problems by recommending the use of the GOB header for every GOB. In addition, treating the GOB boundary as the picture boundary during the encoding will further improve the visual quality in the presence of packet loss. Several simulations during ITU meetings on H.324 Mobile have also demonstrated its effectiveness and desirability. The encoding strategy of each implementation of H.263 codec is beyond the scope of this document, even though it has very significant impact on visual quality in the presence of packet loss. 5.4 Macroblock Address As specified by H.261, macroblock address (MBA) is encoded with a variable length code to indicate the position of a macroblock within a group of blocks in the H.261 bitstream. H.263 does not code the MBA explicitly, but the macroblock address within a GOB is necessary to recover the decoder state in the presence of packet loss. We propose to include this information in the H.263 payload header for two of the modes (Mode B and Mode C) that allow packetization at MB boundaries. 6. Usage of RTP When transmitting H.263 video streams over the internet, we will directly packetize the output of the encoder. All the bits resulting from the bitstream including the fixed length codes and variable length codes (Huffman codes, or SAC if SAC is used) will be included in the packet. Also we do not intend to multiplex audio and video signals in the same packets, as UDP and RTP provide a much more efficient way to achieve multiplexing. RTP does not guarantee a reliable and orderly data delivery service, so a packet might get lost in the network. To achieve a best-effort recovery from packet loss, the decoder needs assistance to proceed with decoding of other packets that are received. Thus it is desirable to be able to process each packet independent of other packets. Like H.261 RTP payload format, we propose to include some frame level information in each packet, such as source format and flags for optional features to assist the decoder in operating efficiently. The H.263 video stream will be carried as payload data within the RTP packets. A new H.263 payload header is defined in section 7, H.263 payload header. This section defines the usage of RTP fixed header and H.263 video packet structure. 6.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 stream: 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. 0 otherwise. Payload Type (PT): The Payload Type shall specify H.263 video payload format. Timestamp: The RTP Timestamp encodes the sampling instance of the first video frame contained in the RTP data packet. The RTP timestamp may be the same on successive packets if a video frame occupies more than one packet. For H.263 video stream, the RTP timestamp is based on a 90 kHz clock, the same as that of RTP payload for H.261 stream. 6.2 Video Packet Structure H.263 compressed bitstream is carried as payload within each RTP packet. For each RTP packet, the RTP header is followed by the H.263 payload header, which is followed by the standard H.263 compressed bitstream. The size H.263 payload header is variable depending on modes used as detailed in the next section. The layout of the RTP H.263 video packet is shown as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |H.263 Payload Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |H.263 stream | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7. H.263 Payload Header One H.263 payload header is present for each H.263 video packet as carried within one RTP packet. Three formats (Mode A, Mode B and Mode C) are defined for RTP H.263 payload. In Mode A, a H.263 payload header of four bytes is present before actual compressed H.263 video bitstream in the packet. It allows fragmentation at GOB boundaries. In Mode B, a eight byte H.263 payload header is used and each packet starts at MB boundaries with PB frame option off. Finally, Mode C with a 12 bytes header is provided to support fragmentation at MB boundaries for frames that are coded with PB frame option on. The mode is indicated by the F field and P field in the first two bits of the header. The three modes can be intermixed for one compressed frame. All the modes should be supported by the client application or its drivers. In this section, the H.263 payload format is shown as rows of 32-bit double word. Within each double word, the high order byte shall be transmitted before the low order byte and bits within a byte shall be transmitted in decreasing order, most significant bit first. 7.1 Mode A In this mode, H.263 bitstream will be packetized at GOB boundaries. In other words, each packet will start at the beginning of a GOB, and it can carry one or more MBs or GOBs. Only four bytes are used for the header. Mode A can be used with or without PB frame option. For those GOBs that are smaller than network packet size, this mode is recommended. The H.263 payload header definition for Mode A is shown as follows with F=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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT |EBIT | SRC | R |I|A|S|DBQ| TRB | TR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F: 1 bit The flag bit indicates the format of the header. F=0, Mode A, F=1, Mode B or Mode C. P: 1 bit Optional PB-frame mode as defined by the H.263 [4]. "0" implies normal I or P picture, "1" PB-frame. When F=1, P also indicates modes. Mode B if P=0, Mode C if P=1. SBIT: 3 bits Start bit position specifies number of bits that should be ignored in the first data byte. EBIT: 3 bits End bit position indicates number of bits that should be ignored in the last data byte. SRC : 3 bits Source format specifies the resolution of the frames contained as defined by the H.263 [4]. R: 5 bits Reserved, must be 0. I: 1 bit. Set to 1 if current picture is intra-coded. Otherwise 0. Notice this is opposite to the picture coding type in PTYPE as defined within the H.263 bitstream [4]. A: 1 bit Optional Advanced Prediction mode as defined by H.263 [4]. "0" implies off, "1", implies on. S: 1 bit Optional Syntax-based Arithmetic Code mode as defined by the H.263 [4]. 0" off, "1" on. DBQ: 2 bits Differential quantization parameter to calculate quantizer for the B frame based on quantizer for the P frame, when PB frame option is on. The value should be the same as DBQUANT defined by the H.263 [4]. Set to 0 if PB frame option is off. TRB: 3 bits Temporal Reference for the B frame as defined by the H.263 [4]. Set to zero if PB frame option is off. TR: 8 bits Temporal Reference for the P frame as defined by the H.263 [4]. Set to zero if PB frame option is off. 7.2 Mode B In this mode, the H.263 stream can be fragmented at MB boundaries. Thus necessary information is needed at the start of the packet to recover the decoder internal state in the presence of packet loss. It is intended for those GOBs whose sizes are larger than the maximum packet size allowed in the underlining protocol (such as IP). This mode can only be used with PB frame option off. Mode C as defined in the next section can be used to fragment at MB boundaries with PB frame option on. The H.263 payload header definition for Mode B is shown as follows with F=1 and P=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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT |EBIT | SRC | QUANT |I|A|S| GOBN | MBA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMV1 | VMV1 | HMV2 | VMV2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following fields are defined the same as in Mode A: F, P, SBIT, EBIT, SRC, I, A, S. The new fields are defined as follows: QUANT: 5 bits Quantization value for the first MB coded at the starting of the packet. Set to 0 if the packet begins with a GOB header. This is the equivalent of GQUANT defined by the H.263 [4]. GOBN: 5 bits GOB number in effect at the start of the packet. GOB number is specified differently for different resolutions. See H.263 [4] for details. MBA: 8 bits The absolute address of the first MB within its GOB. Unlike in H.261, MB address is not coded explicitly in the bitstream. Instead, MB position is decided relative to its immediate previous MB. In order to continue decoding in the presence of loss of the previous packet, the absolute address of the first MB within its GOB in the packet is coded in the header. HMV1, VMV1, 8 bits each. Horizontal and vertical motion vector predictors for the first MB coded in this packet from the MB on the left. The same as MV1 defined by H.263 [4]. We strongly recommend using GOB header for every GOB. HMV2, VMV2, 8 bits each. Horizontal and vertical motion vector predictors from the block or MB on the left of block number 3 in the current MB when advanced prediction option is on. it is the same as MV1 defined for block number 3 in H.263 [4]. This is needed because block number 3 in the first MB needs the motion vector predictor >from the block to its left, as block number 1. These two fields are not used when advanced prediction is off and must be set to 0 See the H.263 [4] for block organization in a frame. 7.3 Mode C In this mode, H.263 stream can be fragmented at MB boundaries of P frames when the PB frame option is on. It is intended for those GOBs whose sizes are larger than the maximum packet size allowed in the underlining protocol (such as IP). H.263 payload header definition for Mode C is shown as follows with F=1 and P=1: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT |EBIT | SRC | QUANT |I|A|S| GOBN | MBA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMV1 | VMV1 | HMV2 | VMV2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TR |DBQ| TRB | R | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following fields are defined the same as in Mode A: F, P, SBIT, EBIT, SRC, I, A, S, TR, DBQ, TRB, and the rest of the fields are defined the same as in Mode B, except field R of 19 bits is reserved and must be set to zero. 7.4 Selection of Modes for H.263 Payload Header Mode A, B and C can be intermixed. The modes shall be selected carefully based on performance characteristics, H.263 coding modes and underlying network protocols. The major advantage of Mode A over Mode B and C is its simplicity. The header is one half and one third of the size of Mode B and C respectively. Transmission overhead is reduced and the savings may be very significant when working with very low bit rates, especially when low latency is desired. Another advantage of Mode A is that it simplifies error recovery in the presence of packet loss. The internal state of the decoder can be recovered at GOB boundaries instead of having to deal with MBs as in Mode B and C, this is because the GOB header and the picture start code are easy to identify. This mode is recommended for GOBs whose size is smaller than the network packet size. The major disadvantage of Mode A is lack of flexibility in packetization and that it does not work when a GOB is larger than the network packet size. Mode B has the advantage of flexibility with fragmentation at MB boundaries with PB frame option off. This mode is necessary when a GOB is larger than the network packet size. It has the disadvantage of higher overhead with a long header of 8 bytes. For small packets, this may not be desirable. Mode C is the same as B, except it allows fragmentation with PB option on at the price of 4 additional bytes. On the other hand, we would like to emphasize that recovery from packet loss will depend on the decoder's ability to use the information provided in the H.263 payload header within the RTP packets. 8. References [1] Henning Schulzrinne, Stephen Casner, Ron Frederick, Van Jacobson, RTP : A Transport Protocol for Real-Time Applications, RFC 1889, 1996. [2] Video Codec for Audiovisual Services at px64 kbits/s, ITU-T Recommendation H.261, 1993 [3] RTP Profile for Audio and Video Conference with Minimal Control, 1995. [4] Video Coding for Low Bitrate Communication, ITU-T Recommendation H.263 (draft) , 1995 [5] T. Turletti, C. Huitema, RTP Payload Format for H.261 Video Stream. 1995. 9. Author's Address Chunrong "Chad" Zhu Mail Stop: JF2-78 Intel Architecture Lab Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA Tel: (503) 264-8849 Fax: (503) 264-6067 Email: czhu@ibeam.intel.com Table of Contents 1. Status of This Memo..................................1 2. Abstract and Document Scope..........................4 3. Introduction.........................................4 4. Definitions..........................................4 5. Design Issues for Packetizating H.263 Bitstream......5 5.1 Optional Features of H.263...........................5 5.2 GOB Numbering........................................6 5.3 Motion Vectors Encoding..............................6 5.4 Macroblock Address...................................7 6. USAGE OF RTP.........................................7 6.1 RTP Header usage.....................................7 6.2 Video Packet Structure...............................8 7. H.263 Payload Header.................................8 7.1 Mode A...............................................9 7.2 Mode B..............................................10 7.3 Mode C..............................................11 7.4 Selection of Modes for H.263 Payload Header.........11 8. References..........................................12 9. Author's Address....................................13 From rem-conf-request@es.net Sat Feb 10 07:59:22 1996 X400-Received: by mta osi-west.es.net in /PRMD=ESnet/ADMD= /C=US/; Relayed; Sat, 10 Feb 1996 04:58:23 -0800 X400-Received: by /PRMD=IIHE/ADMD=RTT/C=BE/; Relayed; Sat, 10 Feb 1996 04:56:19 -0800 X400-Received: by /PRMD=IIHE/ADMD=RTT/C=BE/; Relayed; Sat, 10 Feb 1996 05:43:09 -0800 X400-Received: by /PRMD=iihe/ADMD=rtt/C=be/; Relayed; Sat, 10 Feb 1996 05:43:09 -0800 Date: Sat, 10 Feb 1996 05:43:09 -0800 X400-Originator: colin@helios.iihe.rtt.be X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=iihe/ADMD=rtt/C=be/;960210134309] X400-Content-Type: P2-1984 (2) Content-Identifier: 18820000 From: Michel Colin Message-ID: <18820000*/G=michel/S=colin/O=helios/PRMD=iihe/ADMD=rtt/C=be/@MHS> To: Gary Veum (Non Receipt Notification Requested) Cc: "(Peter Parnes)" (Non Receipt Notification Requested), rem-conf (Non Receipt Notification Requested) Subject: Re: wb on solaris 2.5? Gary veum' mail: >> Excerpts from Peter Parnes's mail: >> ] >> ] jaw@ucs.ed.ac.uk said: >> ] > It works fine for me provided that I don't use Display PostScript to = >> ] > rasterize the PostScript. This never seemed to work very well on = >> ] > Solaris 2.4 either or on SGIs. I always force wb to use ghostscript. = >> ] > You can do this by setting the following X resource: >> ] > wb.UseDPS: false = >> ] >> ] >> ] I'm have been using Wb with DPS under Sol2.4 and 2.5 for some time now. T= >> ] here were some DPS problems under 2.4/XSun that were fixed by some Solari= >> ] s-patch (if it's important I find out which one it is) but besides that i= >> ] t works fine under 2.4/2.5. >> >> peter, >> >> we discovered we need to fine tune the question. is anyone using wb on >> solaris 2.5 with a SX framebuffer? Graeme was using on a b/w system. >> we've tried on with and w/o using CDE and other window managers. >> >> thanks. >> -gv Garry, I'm using Solaris 2.5 on a Sparc20 SX. WB works fine using DPS to display postscript files. I was using CDE as window managers. Michel =============================================================================== Michel Colin Tel. +32-2-650 57 03 Fax: +32-2-629 38 16 Universite Libre de Bruxelles - Service Telematique et Communication CP 230, Boulevard du triomphe - b-1050 bruxelles - BELGIUM RFC822: colin@helios.iihe.rtt.be X.400 : C=be;ADMD=rtt;PRMD=iihe;O=helios;S=colin; X.500 : @c=be@o=Universite Libre de Bruxelles@ou=Faculte des Sciences@ou=Service Telematique et Communication@cn=Michel Colin ------------------------------------------------------------------------------- From rem-conf-request@es.net Sat Feb 10 15:45:50 1996 Received: from realtime.cc.missouri.edu by osi-west.es.net with ESnet SMTP (PP); Sat, 10 Feb 1996 12:44:54 -0800 Received: (from ccshag@localhost) by realtime.cc.missouri.edu (8.7.1/8.7.1) id OAA01567; Sat, 10 Feb 1996 14:44:48 -0600 (CST) Date: Sat, 10 Feb 1996 14:44:47 -0600 (CST) From: Paul 'Shag' Walmsley X-Sender: ccshag@realtime.cc.missouri.edu To: rem-conf@es.net cc: MU Multicast Transmission Group , muiit-l@lists.missouri.edu Subject: Feb 12: "The Condition of Virtuality" - N. Katherine Hayles Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This Monday, February 12, Dr. N. Katherine Hayles of the University of California-Los Angeles will present a seminar at the University of Missouri-Columbia entitled "The Condition of Virtuality." The seminar will start at 3:40 PM CST (2140 GMT). We intend to multicast this seminar over the MBONE. We have advertised the following media types in sd with a ttl of 127: - PCM audio: 224.2.228.112, port 53385, cid 10825 - nv video: 224.2.231.117, port 65021 - wb whiteboard: 224.2.132.97/60457/25281 As usual, we will stand by to reduce video bandwidth from our starting point of 128Kbps if necessary. Multicast reception feedback and other administrivia should be sent to the MU Multicast Transmission Group at . More information on the seminar and the sponsoring groups can be found at . Some biographical information on Dr. Hayles: N. Katherine Hayles holds an MA in Chemistry from the California Institute of Technology and a PhD in English from the University of Rochester. She has taught at the University of Iowa, where she was Millington F. Carpenter Professor of English, at CalTech, at Dartmouth, and at the University of Missouri-Rolla. Professor Hayles teaches Literature and Science of the Twentieth Century; Modern and Post-Modern Fiction; and Critical Theory. She has written extensively in these fields. One of her more important books is Chaos Bound: Orderly Disorder in Contemporary Literature and Science (Ithaca, N.Y.: Cornell University Press, 1990). She edited the companion volume Chaos and Disorder: Complex Dynamics in Literature and Science (Chicago: University of Chicago Press, 1991). Professor Hayles uses computer technology extensively in several different teaching environments, ranging from an upperclass undergraduate course, "The American Experience with Intelligent Machines," to a graduate course on implications of hypertext for literary theory and practice. In the summer of 1995 she directed a NEH Summer Seminar for College Teachers entitled "Literature in Transition: The Implications of Electronic Textuality." - Paul "Shag" Walmsley "Praise and blame alike mean nothing." -- Virginia Woolf From rem-conf-request@es.net Sat Feb 10 17:18:56 1996 Received: from blob.best.net by osi-west.es.net with ESnet SMTP (PP); Sat, 10 Feb 1996 14:18:16 -0800 Received: from mg131-032.ricochet.net (mg131-032.ricochet.net [204.179.131.32]) by blob.best.net (8.6.12/8.6.5) with SMTP id OAA07185; Sat, 10 Feb 1996 14:18:08 -0800 Date: Sat, 10 Feb 1996 14:18:08 -0800 Message-Id: <1.5.4b11.16.19960210141741.112fe304@pop.best.com> X-Sender: rsf@pop.best.com X-Mailer: Windows Eudora Light Version 1.5.4b11 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Stephen Casner , rem-conf@es.net From: Ross Finlayson Subject: Re: AVT session at Los Angeles IETF? At 05:06 PM 2/5/96 -0800, Stephen Casner wrote: >A couple of people have suggested the Audio/Video Transport working >group should meet at the upcoming IETF meeting in Los Angeles. I'd be >happy to chair a session there, and Allison Mankin says it is possible >to fit an AVT session into the schedule. > >The question is: What shall we discuss? ... >I'd like to hear more from those who sent the recent suggestions and >from any others of you who would like to suggest topics Steve, As the person responsible for starting this thread, I feel obliged to follow up on this :-) My original message was motivated by concern about the myriad of seemingly non-interoperable A/V technologies that have been flooding the marketplace recently. It was encouraging to learn that the recent announcement by Netscape & Progressive Networks (& other companies) was talking about the IETF's "RTP" after all. Nonetheless, I think that the IETF has a role to play in "keeping them honest" by continuing to encourage interoperability and standardization. While it's inevitable that some companies will introduce their own extensions (the "grab market share first; promote as de-facto standards second" approach), we can at least provide a forum in which the technical merits of such extensions can be discussed. (I'd hate to see RTP equivalents of :-) So, one topic for discussion in Los Angeles could be: What role, if any should the IETF play in encouraging interoperability by applications that use RTP, and in standardizing future extensions and encodings? It might also be useful to solicit brief presentations by representatives of organizations (e.g., including those mentioned in the recent press release) who are developing RTP-compliant applications. This might be a good way to identify any 'gotchas' that may motivate future changes or extensions. However, the LA meeting may be too early (& on too short notice) for such "status reports". It might be better to leave these until the following IETF (Montreal). There's also an organizational question: Do we really need both a "mmusic" ("conference control") group and an "avt" group? Mark Handley has already noted that by starting to address ITU interoperability issues, the "mmusic" group is starting to branch out into more AVT-like areas. And Vinay Kumar has suggested adopting RTP for use by applications other than audio/video. So maybe it's time to merge the existing "mmusic" and "avt" working groups into a single "conferencing" working group. I notice that two "mmusic" sessions are already scheduled for Los Angeles, so rather than scheduling a new session for "avt", maybe we could use part of one of the "mmusic" sessions to discuss how to continue these groups? Ross. From rem-conf-request@es.net Mon Feb 12 13:23:47 1996 Received: from noc4.dccs.upenn.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 12 Feb 1996 10:23:09 -0800 Received: from UPENN5.HEP.UPENN.EDU by noc4.dccs.upenn.edu id AA23630; Mon, 12 Feb 96 13:23:01 -0500 Return-Path: Received: by upenn5.hep.upenn.edu id NAA08077; Mon, 12 Feb 1996 13:22:55 -0500 Date: Mon, 12 Feb 1996 13:22:55 -0500 From: keener@upenn5.hep.upenn.edu (Paul T. Keener) Posted-Date: Mon, 12 Feb 1996 13:22:55 -0500 Message-Id: <199602121822.NAA08077@upenn5.hep.upenn.edu> To: rem-conf@es.net Subject: ENIAC 50th anniversary celebration broadcast The University of Pennsylvania will be broadcasting the ENIAC 50th anniversary Speech, "The Technology Challenge: Can America Spark Private Innovation?" by Vice President Al Gore and the ceremonial reactivation of a piece of the original ENIAC on the mbone on Wednesday 14 February 1996 starting at 1150 EST and running until 1330 EST. More information on the broadcast is available at http://www.seas.upenn.edu/~museum/mbone.html and more information on the celebration is available at http://www.seas.upenn.edu/~museum The technical contacts for this broadcast are Paul T. Keener keener@upenn5.hep.upenn.edu 215 898 0135 Norm Morrison morrison@lrsm.upenn.edu Paul T. Keener Department of Physics and Astronomy University of Pennsylvania From rem-conf-request@es.net Mon Feb 12 23:05:33 1996 Received: from plateau.cs.Berkeley.EDU (actually bugs-bunny.CS.Berkeley.EDU) by osi-west.es.net with ESnet SMTP (PP); Mon, 12 Feb 1996 20:04:56 -0800 Received: from garfield.CS.Berkeley.EDU (garfield.CS.Berkeley.EDU [128.32.32.118]) by plateau.cs.Berkeley.EDU (8.6.11/8.3) with ESMTP id TAA20034; Mon, 12 Feb 1996 19:56:49 -0800 Received: from garfield.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by garfield.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id TAA22589; Mon, 12 Feb 1996 19:59:50 -0800 Message-Id: <199602130359.TAA22589@garfield.CS.Berkeley.EDU> From: Andrew Swan To: 298@bugs-bunny.CS.Berkeley.EDU cc: rowe@cs.berkeley.edu Subject: UC Berkeley Multimedia Seminar 2/14/96 - "Collaborative Computing from the Home" X-URL: http://www.cs.berkeley.edu/~aswan/ Date: Mon, 12 Feb 1996 19:59:50 -0800 Sender: aswan@bugs-bunny.CS.Berkeley.EDU The fourth Berkeley Multimedia and Graphics seminar of the Spring 1996 semester will be held Wednesday, February 14 from 12:30 - 2:00 PST in 405 Soda Hall. The speaker will be Gordon Bell of Microsoft Research, discussing "Collaborative Computing from the Home" The talk will be broadcast on the Internet MBONE, beginning at roughly 12:40 PM PST. Please note that you will need vic 2.7 to watch the broadcast. Pre-compiled vic binaries for most architectures are available from: ftp://ftp.ee.lbl.gov/conferencing/vic/alpha-test/ We also hope to broadcast the seminar on the BAGNet -- an sd advertisement should appear by the time the seminar starts. Questions should be directed to Larry Rowe (rowe@cs.berkeley.edu) Abstract: Telework aka telepresence for work, can be characterized in three dimensions: 1. the enabling technology or product (how its done); 2. the organizational structure (who is doing it); and 3. the type of work (what is being done). Many factors limit telework: communciation bandwidth, products, the activities themselves, etc. As an advanced development organization for a product company, we want to explore telework technology and product potential. In short, we're looking for killer apps. -- Andrew Swan aswan@cs.berkeley.edu Plateau Multimedia Research Group http://www.cs.berkeley.edu/~aswan/ From rem-conf-request@es.net Tue Feb 13 01:57:13 1996 Received: from upeksa.sdsc.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 12 Feb 1996 22:56:19 -0800 Received: by upeksa.sdsc.edu for rem-conf@es.net id WAA15760; Mon, 12 Feb 1996 22:56:17 -0800 From: kc@upeksa.sdsc.edu (k claffy) Message-Id: <199602130656.WAA15760@upeksa.sdsc.edu> Subject: NANOG (north american network operators group) february 15-16 meeting multicast To: rem-conf@es.net Date: Mon, 12 Feb 1996 22:56:17 -0800 (PST) X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Content-Type: text Content-Length: 490 we plan to multicast the february NANOG, february 15 and 16th [1.5 days]. http://www.merit.edu/routing.arbiter/NANOG/mtg-9602/agenda.html has the agenda http://www.nlanr.net/nanog has other details [meeting is from 0900-1700 pacific time thursday feb 15 and 0900-1315 pacific friday feb 16] we'll announce the (audio/video/wb) sessions in sd as 'nanog' and post the multicast address details wednesday. please let us know if there are any problems/conflicts. tnx kc@nlanr.net From rem-conf-request@es.net Tue Feb 13 05:18:06 1996 Received: from gateway-gw.pictel.com by osi-west.es.net with ESnet SMTP (PP); Tue, 13 Feb 1996 02:17:32 -0800 Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA14904; Tue, 13 Feb 96 05:17:30 EST Received: from smtpnotes.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) id AA17193; Tue, 13 Feb 96 05:14:50 EST Received: by smtpnotes.pictel.com (4.1/SMI-4.1) id AA02888; Tue, 13 Feb 96 05:14:50 EST Message-Id: <9602131014.AA02888@smtpnotes.pictel.com> Received: from PicTel with "Lotus Notes Mail Gateway for SMTP" id FE8978ECBC96004B852562CE005E44DC; Tue, 13 Feb 96 10:14:48 To: imtc Cc: h32z2-list , rem-conf , Gary Thom , Dale Skran , Sakae Okubo , Neil Starkey From: Rich Baker/PicTel Date: 13 Feb 96 5:07:32 EDT Subject: H.323 IMTC Meeting, Tel Aviv, 15-18 Apr 96 Mime-Version: 1.0 Content-Type: Text/Plain To: IMTC Corporate Network Conferencing AG members All participants at Ipswich AVC meeting From: Rich Baker, Chair IMTC CNC AG) Dear IMTC CNC AG members and H.323 experts: I am writing to invite you to a special meeting of the IMTC Corporate Network Conferencing Activity Group to be held 15-18 April 95 in Tel Aviv, Israel, and graciously hosted by RADVision Ltd. As you may know, the final White contribution versions of draft Rec. H.323 and H.225.0 have been submitted for the May 1996 meeting of ITU-T Study Group 15, with the intention of being approved ("Decision") at that time. The H.323 expert's group under Rapporteur Sakae Okubo, H.323 editor Gary Thom and H.225.0 editor Dale Skran has done an excellent job developing these documents in record time, which are key to advancing the entire conferencing industry. I understand that all the remaining open issues on these documents were resolved at the Ipswich AVC meeting during the week of January 15. Closing these issues required the editors to complete a great deal of editorial work during the meeting and in the single week following in order to meet the SG15 White contribution deadline. But experience tells us that, despite the best efforts of the editors and experts, it is unrealistic to expect that these numerous editorial changes could be incorporated flawlessly in the few days available. So in the interest of delivering a strong, stable, and technically correct standard which will enable implementors to build compatible terminals and hosts, a number of the experts involved have suggested the need for a collective review of the final White documents prior to the SG15 meeting, with ample time for focused work to ensure that these documents fully reflect the agreements of Ipswich in a clear, unambiguous, and technically correct way. Hence, this meeting in Tel Aviv. Please note that the meeting is not sponsored by the ITU; it is a meeting of IMTC members and guests concerned with the editorial correctness of H.323 and H.225.0. As such, it would be inappropriate in Tel Aviv to change decisions made by Rapporteur Okubo's Experts Group. However, it is entirely appropriate for representatives within the IMTC to identify any errors or ambiguity in the White documents and to suggest editorial improvements. The IMTC, as a California corporation, can then propose contributions to SG15 via the normal United States approval process through US Study Group C. (The deadline for SGC submissions prior to SG15's meeting is 24 Apr 96.) The ITU-T process is such that proposals for substantive changes at this stage are very unlikely to be accepted and could cause the documents to be considered not ready for approval. Therefore, to ensure the maximum chance of SG15 approval in May, while allowing us to focus productively on improving the existing White documents, I am establishing the following rules for our meeting: GROUND RULES * We will carefully review the H.323 and H.225.0 White documents for TECHNICAL CORRECTNESS, TECHNICAL CLARITY, and MINOR EDITORIAL CHANGES. * NO proposals for changes to decisions already reflected in the White Documents will be considered, unless it can be shown that an existing method specified in the text is technically unworkable, violates the Ipswitch agreements, or is technically inconsistent with the rest of the document. * All written contributions to the meeting must be in the form of proposed alternate text to the White documents, listed by section number in H.323 or H.225.0, or will not be considered. * All written contributions must be posted on the H.323 reflector (h32z2-list @ mtgbcs.mt.att.com) in final form, with a document number assigned by me at least 7 days before the start of our meeting. * Authors must bring 40 copies of each contribution to the meeting, marked with the assigned document number. (Let's not waste our time standing over a photocopier!) Contributions which do not meet these requirements will not be considered at the meeting. OUTPUT DOCUMENTS Our output will be a list of proposed changes to the White documents H.323 and H.225.0. We must work to keep this list as small as possible, while correcting all critical problems with the documents. Two change lists (one each for H.323 and H.225.0) will then be proposed to US SG C as U.S. contributions for the May SG15 meeting. MEETING PROCESS Our meeting will do a careful section-by-section review of the White Paper documents, checking for MEANING, TECHNICAL CLARITY, TECHNICAL CORRECTNESS, SELF CONSISTENCY, and matching previously agreed upon INTENT. Our objective is to ensure the text accurately reflects agreements already made by Rapporteur Okubo's experts group, is interpreted by us all in the same way, and will work (no holes). I look forward to seeing you in Tel Aviv for this final critical review of these documents. Cheers! Rich Baker, Chair IMTC CNC AG bake@pictel.com +1.508.623.4459 MEETING DETAILS: More details will be posted in the next few days to the newsgroups/reflectors above. For now: Host: RADVision Meeting Place: Tel Aviv, in hotel large enough to accommodate all participants Host Contact: Registration: Accommodations: Local Transport: Directions: Mailing instructions: Weather: I'd wager it will be pretty darn warm! (-: From rem-conf-request@es.net Tue Feb 13 09:44:51 1996 Received: from agora.stm.it by osi-west.es.net with ESnet SMTP (PP); Tue, 13 Feb 1996 06:44:01 -0800 Received: from netman.agora.stm.it (agora.stm.it [194.20.43.1]) by agora.stm.it (8.6.8.1/8.6.6) with SMTP id PAA17448; Tue, 13 Feb 1996 15:42:43 GMT Date: Tue, 13 Feb 1996 15:42:43 GMT Message-Id: <199602131542.PAA17448@agora.stm.it> X-Sender: m.degregorio@hella.stm.it X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: w-bone@mrrl.lut.ac.uk, rem-conf@es.net From: Maurizio de Gregorio Subject: NCSA Common Client Interface ? Reading the documentation of NCSA CCI interface I've noted that the most recent update is July 1995. What is the reason? Did they abandon this project? If they did, what are they now working on? Thanks Maurizio __________________________________________________ Maurizio de Gregorio University of Florence Firenze (ITALY) Tel: +39-55-486530 e-mail: m.degregorio@agora.stm.it __________________________________________________ From rem-conf-request@es.net Tue Feb 13 13:45:22 1996 Received: from noc4.dccs.upenn.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 13 Feb 1996 10:44:52 -0800 Received: from UPENN5.HEP.UPENN.EDU by noc4.dccs.upenn.edu id AA14281; Tue, 13 Feb 96 13:44:50 -0500 Return-Path: Received: by upenn5.hep.upenn.edu id NAA26163; Tue, 13 Feb 1996 13:44:43 -0500 Date: Tue, 13 Feb 1996 13:44:43 -0500 From: keener@upenn5.hep.upenn.edu (Paul T. Keener) Posted-Date: Tue, 13 Feb 1996 13:44:43 -0500 Message-Id: <199602131844.NAA26163@upenn5.hep.upenn.edu> To: rem-conf@es.net Subject: ENIAC mbone broadcast test Cc: morrison@lrsm.upenn.edu This afternoon around 1530, we will be running a 5-10 minute test for the ENIAC 50th Celebration broadcast tomorrow. We would appreciate if anyone could tune in and give us feedback. Mail can be sent to me at keener@upenn5.hep.upenn.edu. We will run the test on the sd advertised session. The parameters are 224.2.217.176 audio: 56039/28420 video: 53998/55391 Thank you. Paul T. Keener Department of Physics and Astronomy University of Pennsylvania From rem-conf-request@es.net Wed Feb 14 00:49:29 1996 Received: from hplms26.hpl.hp.com by osi-west.es.net with ESnet SMTP (PP); Tue, 13 Feb 1996 21:49:02 -0800 Received: from hplabsz.hpl.hp.com by hplms26.hpl.hp.com with ESMTP ($Revision: 1.36.108.11 $/15.5+ECS 3.3+HPL1.1S) id AA072726925; Tue, 13 Feb 1996 21:48:45 -0800 Received: by hplabsz.hpl.hp.com (1.37.109.15/15.5+ECS 3.3+HPL1.1) id AA088486925; Tue, 13 Feb 1996 21:48:45 -0800 From: Laura de Leon Message-Id: <199602140548.AA088486925@hplabsz.hpl.hp.com> Subject: BayLISA: Carl Rigney on the Radius Protocol To: baylisa@baylisa.org, rem-conf@es.net, sage-members@usenix.org Date: Tue, 13 Feb 96 21:48:45 PST Mailer: Elm [revision: 70.85.2.1] 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. We meet at Synopsys Building C in Mountain View, California off Highway 237 at Middlefield. The meetings are also broadcast via MBONE. Schedule -------- February 15: Carl Rigney, Livingston Enterprises, IETF Radius Working Group Chair RADIUS (Remote Authentication Dial In User Service) is a protocol used by Network Access Servers (such as terminal servers or on-demand routers) to safely query a remote database server to authenticate a dial in user and receive authorization information describing what kind of service to provide for the user. RADIUS Accounting extends RADIUS to allow the Network Access Server to also send usage information to a remote server. The talk will describe what RADIUS is, how it works, what it can do, where to get it, and where it's going. There'll be a Question & Answer session afterwards. March 21: Dan Appelman, Lawyer speaking on the recent telecom legislation, and its impact on Systems Administrators. [Schedule subject to change] 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. From rem-conf-request@es.net Wed Feb 14 09:47:25 1996 Received: from mail.med.cornell.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 14 Feb 1996 06:46:41 -0800 Received: from [140.251.155.200] (mac101385.med.cornell.edu [140.251.155.200]) by mail.med.cornell.edu (8.7/8.7/ech2.01) with SMTP id JAA04348 for ; Wed, 14 Feb 1996 09:46:37 -0500 (EST) Date: Wed, 14 Feb 1996 09:46:37 -0500 (EST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: mwburne@mail.med.cornell.edu (Michael Burnett) Subject: unsubscribe unsubscribe Michael Burnett Cornell University Medical College From rem-conf-request@es.net Thu Feb 15 09:36:20 1996 Received: from radvision.rad.co.il by osi-west.es.net with ESnet SMTP (PP); Thu, 15 Feb 1996 06:35:01 -0800 Received: from gateway.radvision.rad.co.il by blue.radvision.rad.co.il (4.1/SMI-4.1) id AA00547; Thu, 15 Feb 96 16:24:05 IST Received: by gateway.radvision.rad.co.il with Microsoft Mail id <3123CF78@gateway.radvision.rad.co.il>; Thu, 15 Feb 96 16:27:36 PST From: Ami Amir To: rem-conf@es.net, Rubin Gruber , Jim Goodwin , IMTC Members , h32z2-list , Giles Willoughby , Dave Agans Cc: Zohar Zisapel , shykeh gordon , Revital Cohen , Eli Doron , Dani Levin Subject: IMTC/H.323 - Administrative Details Date: Thu, 15 Feb 96 16:26:00 PST Message-Id: <3123CF78@gateway.radvision.rad.co.il> Encoding: 216 TEXT X-Mailer: Microsoft Mail V3.0 Dear Coleagues, IMTC members and H.323 Experts (that sums up everybody, doesn't it?) You are cordially invited to the IMTC Corporate Network Conferencing Activity Group to be held 15-18 April 95 in Tel Aviv, Israel. RADVision will be happy to host you for the meeting. Location: The Sheraton Hotel, Hayarkon Street Tel Aviv Two meeting rooms, lunch and refreshments are provided for. Accomodations: The Sheraton is located in Tel Aviv's hotel strip by the beach. You may choose a hotel according to your budget and personal preferences >from the following list (special rates have been arranged - please indicate that you are part of the IMTC/RAD rates). All rates include a buffet style breakfast. The Sheraton - (5 star) $180 The Yamit - (4 star) $91 less than 5 minute stroll Hotel Basel - (4 star) $70 less than 3 minutes walk, smaller rooms All major credit cards are accepted. ATM machines will provide local currency (3 sheqels = $1.0). For administrative reasons, we ask that you make your reservations with our Office Manager: Ms. Revital Cohen revitalc@radvision.rad.co.il; tel:+972/3/645-5220; fax:+972/3/647-6669. Last minute changes and any special requests and questions - hotel contacts: Sheraton "Ganani Reservations" via Phone/Fax +972/3/547-0398 Yamit Phone - +972/3/519-7111, Fax - +972/3/517-4719 Basel Phone - +972/3/546-8126, Fax - +972/3/546-7687 How to get here: All major European Airlines plus El Al and TWA (both with direct flights >from JFK or EWR) land here. El Al also has direct flights from the Far East. Ben Gurion Airport is 30 minutes away. Take a cab to the hotel. It is about 60 NIS - New Israeli Sheqel, equivalent to $20. Get some local currency at the airport's ATM machines or banks. In dire straits - cabs will accept dollars. Local Transportation: It is recommended that you do not rent cars ahead of time, and if you wish to pick up a car for a day or so, many rental offices are around the corner. Cabs are cheap and almost everything is within walking distance. Dress Code: Tel Aviv is VERY informal, no ties, suits. You may bring a jacket and/or pullover for an evening stroll. No "dress code" in restaurants or bars (although shorts and sandals are frowned upon in some of the better places). Weather: Averaging 25 deg C (70 deg F), hardly any rain, and the beach is a stone's throw away from the hotels. Communications and E Mail: Keep in mind that hotels' phone bills are exhorbitant. AT&T, MCI and Sprint have local access numbers. Phone jacks in hotels are RJ 11 / DTMF. We will provide you with telnet access via our router (local call). We are also checking with the hotel and the local PTT - Bezeq - might be able to provide ISDN remote access from the hotel. Extracurricular Activities: We are organizing and hosting a bus tour of Jerusalem (it's 40 miles/60km >from Tel Aviv) for Saturday, April 20th. Jerusalem is unique, and should not be missed. We recommend you plan your flights accordingly. Please let us know if you wish to join. We would also like to invite you to a night in town - Wednesday, April 17. Shalom (that's the local "Cheerio") and CU, Ami amir@radvision.rad.co.il +972/3/645-5280 enclosed: Rich Baker's Invitation ======================================================================== To: IMTC Corporate Network Conferencing AG members All participants at Ipswich AVC meeting From: Rich Baker, Chair IMTC CNC AG) Dear IMTC CNC AG members and H.323 experts: I am writing to invite you to a special meeting of the IMTC Corporate Network Conferencing Activity Group to be held 15-18 April 95 in Tel Aviv, Israel, and graciously hosted by RADVision Ltd. As you may know, the final White contribution versions of draft Rec. H.323 and H.225.0 have been submitted for the May 1996 meeting of ITU-T Study Group 15, with the intention of being approved ("Decision") at that time. The H.323 expert's group under Rapporteur Sakae Okubo, H.323 editor Gary Thom and H.225.0 editor Dale Skran has done an excellent job developing these documents in record time, which are key to advancing the entire conferencing industry. I understand that all the remaining open issues on these documents wereresolved at the Ipswich AVC meeting during the week of January 15. Closing these issues required the editors to complete a great deal of editorial work during the meeting and in the single week following in order to meet the SG15 White contribution deadline. But experience tells us that, despite the best efforts of the editors and experts, it is unrealistic to expect that these numerous editorial changes could be incorporated flawlessly in the few days available. So in the interest of delivering a strong, stable, and technically correct standard which will enable implementors to build compatible terminals and hosts, a number of the experts involved have suggested the need for a collective review of the final White documents prior to the SG15 meeting, with ample time for focused work to ensure that these documents fully reflect the agreements of Ipswich in a clear, unambiguous, and technically correct way. Hence, this meeting in Tel Aviv. Please note that the meeting is not sponsored by the ITU; it is a meeting of IMTC members and guests concerned with the editorial correctness of H.323 and H.225.0. As such, it would be inappropriate in Tel Aviv to change decisions made by Rapporteur Okubo's Experts Group. However, it is entirely appropriate for representatives within the IMTC to identify any errors or ambiguity in the White documents and to suggest editorial improvements. The IMTC, as a California corporation, can then propose contributions to SG15 via the normal United States approval process through US Study Group C. (The deadline for SGC submissions prior to SG15's meeting is 24 Apr 96.) The ITU-T process is such that proposals for substantive changes at this stage are very unlikely to be accepted and could cause the documents to be considered not ready for approval. Therefore, to ensure the maximum chance of SG15 approval in May, while allowing us to focus productively on improving the existing White documents, I am establishing the following rules for our meeting: GROUND RULES * We will carefully review the H.323 and H.225.0 White documents for TECHNICAL CORRECTNESS, TECHNICAL CLARITY, and MINOR EDITORIAL CHANGES. * NO proposals for changes to decisions already reflected in the White Documents will be considered, unless it can be shown that an existing method specified in the text is technically unworkable, violates the Ipswitch agreements, or is technically inconsistent with the rest of the document. * All written contributions to the meeting must be in the form of proposed alternate text to the White documents, listed by section number in H.323 or H.225.0, or will not be considered. * All written contributions must be posted on the H.323 reflector (h32z2-list @ mtgbcs.mt.att.com) in final form, with a document number assigned by me at least 7 days before the start of our meeting. * Authors must bring 40 copies of each contribution to the meeting, marked with the assigned document number. (Let's not waste our time standing over a photocopier!) Contributions which do not meet these requirements will not be considered at the meeting. OUTPUT DOCUMENTS Our output will be a list of proposed changes to the White documents H.323 and H.225.0. We must work to keep this list as small as possible, while correcting all critical problems with the documents. Two change lists (one each for H.323 and H.225.0) will then be proposed to US SG C as U.S. contributions for the May SG15 meeting. MEETING PROCESS Our meeting will do a careful section-by-section review of the White Paper documents, checking for MEANING, TECHNICAL CLARITY, TECHNICAL CORRECTNESS, SELF CONSISTENCY, and matching previously agreed upon INTENT. Our objective is to ensure the text accurately reflects agreements already made by Rapporteur Okubo's experts group, is interpreted by us all in the same way, and will work (no holes). I look forward to seeing you in Tel Aviv for this final critical review of these documents. Cheers! Rich Baker, Chair IMTC CNC AG bake@pictel.com +1.508.623.4459 From rem-conf-request@es.net Thu Feb 15 11:15:42 1996 Received: from trystero.radio.com by osi-west.es.net with ESnet SMTP (PP); Thu, 15 Feb 1996 08:15:10 -0800 Received: (carl@localhost) by trystero.radio.com (8.7.1/940816.06ccg) id LAA17822 for rem-conf@es.net; Thu, 15 Feb 1996 11:15:08 -0500 (EST) From: "Carl Malamud [IMS]" Message-Id: <199602151615.LAA17822@trystero.radio.com> Subject: 50th Anniversary of the Computer To: rem-conf@es.net Date: Thu, 15 Feb 1996 11:15:07 -0500 (EST) Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit We'll be multicasting from the ACM's Computing Week 96 for the next couple of days as part of the Internet 1996 World Exposition. The URL for this event is: http://park.org/Events/ACM/ Featured events will include a live talk show with Vint Cerf tonight at 6:30-8PM Eastern Time and a conference session featuring kids, space, astronauts, and the ACM on Friday, February 16, 6:30-8PM. From rem-conf-request@es.net Thu Feb 15 17:10:07 1996 Received: from feline.nrnsinc.on.ca (actually 131.136.194.3) by osi-west.es.net with ESnet SMTP (PP); Thu, 15 Feb 1996 14:09:36 -0800 Received: (from spagnolo@localhost) by feline.nrnsinc.on.ca (8.7.1/8.7.1) id RAA09187; Thu, 15 Feb 1996 17:08:33 -0500 (EST) From: Joe Spagnolo Message-Id: <199602152208.RAA09187@feline.nrnsinc.on.ca> Subject: vat v4.0a2 on Solaris 2.5 To: rem-conf@es.net Date: Thu, 15 Feb 1996 17:08:33 -0500 (EST) Cc: spagnolo@feline.nrnsinc.on.ca (Joe Spagnolo) Reply-to: spagnolo@nrnsinc.on.ca Organization: NRNS Incorporated, Tel:613-599-7860, Fax:613-599-7739 X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello, When I try to run vat v4.0a2 (from vatbin-4.0a2-solaris2.4.tar.gz) on Solaris 2.5, it spits out the following and quits: vat: "vat_main": bad option "colormodel": must be appname I experience the same results from both OpenWindows and CDE. What I am missing? Thanks. -- Joe Spagnolo From rem-conf-request@es.net Thu Feb 15 17:26:07 1996 Received: from nren-vod.arc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Thu, 15 Feb 1996 14:25:37 -0800 Received: by nren-vod.arc.nasa.gov (940816.SGI.8.6.9/1.35) id NAA20403; Thu, 15 Feb 1996 13:43:18 -0800 Date: Thu, 15 Feb 1996 13:43:18 -0800 From: garyp@nren-vod.arc.nasa.gov (Gary Paden) Message-Id: <199602152143.NAA20403@nren-vod.arc.nasa.gov> To: rem-conf@es.net Subject: NASA Shuttle Mission Presentation We are planing an mbone presentation of the NASA Shuttle Mission STS-75. The presentation will take place Feb. 22nd - March 7th. We will be using nv and vat for the entire presentation. If this broadcast conflicts with any previously scheduled broadcast please contact me by phone or by e-mail. Gary Paden NASA Ames/Sterling paden@pioneer.arc.nasa.gov (415)604-0082 From rem-conf-request@es.net Thu Feb 15 19:45:42 1996 Received: from susie.vigra.com (actually susie-10.vigra.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 15 Feb 1996 16:44:40 -0800 Received: from hobbes.vigra.com (hobbes.vigra.com [199.254.9.3]) by susie.vigra.com (8.6.10/Vigra-1.1 Boogie) with ESMTP id QAA27413; Thu, 15 Feb 1996 16:44:26 -0800 Received: (steve@localhost) by hobbes.vigra.com (8.6.10/Vigra-1.1 Boogie) id QAA05994; Thu, 15 Feb 1996 16:43:36 -0800 Date: Thu, 15 Feb 1996 16:43:36 -0800 Message-Id: <199602160043.QAA05994@hobbes.vigra.com> From: Steve Haehnichen To: rem-conf@es.net CC: ramac@physics.att.com Subject: Washington Professional Systems contact info for VC-C1 Reply-to: steve@vigra.com Several people have asked me for contact info for Washington Professional Systems where I bought my Canon VC-C1 from. (Canon refered me to them when I inquired about purchasing a VC-C1, but now Canon USA has no recollection of them. Go figure.) That was almost a year ago, and I haven't dealt with them since, but here's the info: Washington Professional Systems 11242 Grandview Avenue Wheaton Maryland 20902-4663 Phone: (301) 942-6800 Fax: (301) 946-3241 I paid: $1645 Canon VC-C1 Communication Camera 65 wide-angle lens (WD-37) 10 lens adapter (SR27/37) 220 software developer pack (SWK-0001-DPK) I'd be surprised if the prices are still the same, since everyone else seems to be charging more. PicturePhone direct (www.picturephone.com) has the camera for $1995, last I checked. It's a swell camera, but Canon needs to figure out how to sell them. :) -Steve -- Steve Haehnichen Vigra, Inc. San Diego, CA steve@vigra.com (619) 597-7080 x169 Fax: (619) 597-7094 From rem-conf-request@es.net Thu Feb 15 19:56:56 1996 Received: from franc.ucdavis.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 15 Feb 1996 16:56:23 -0800 Received: from DWBTEMP by franc.ucdavis.edu (8.6.12/UCD3.4.3) id QAA28122; Thu, 15 Feb 1996 16:56:20 -0800 Date: Thu, 15 Feb 1996 16:56:20 -0800 Message-Id: <199602160056.QAA28122@franc.ucdavis.edu> X-Sender: fzburger@peseta.ucdavis.edu X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: "David W. Burger" Subject: Unsubscribe UNSUBSCRIBE From rem-conf-request@es.net Thu Feb 15 22:03:14 1996 Received: from atg.apple.com by osi-west.es.net with ESnet SMTP (PP); Thu, 15 Feb 1996 19:02:36 -0800 Received: from [17.255.9.143] (jpallas.atg.apple.com [17.255.9.143]) by atg.apple.com (8.7.2/8.6.12) with SMTP id TAA01202 for ; Thu, 15 Feb 1996 19:03:48 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Feb 1996 19:03:42 -0700 To: rem-conf@es.net From: Pallas@Apple.COM (Joe Pallas) Subject: tools for Wintel? I realize this is a FAQ, but could someone possibly refresh my memory of what tools are available *today* on Windows boxes for receiving multicast VAT audio and NV or VIC/H.261 video? I need to convince someone that multi-platform support for the IETF AVT standards is more than just PR-ware. I'm already aware of: * Netscape's LiveMedia framework * Precept's IP/TV (due in April) * The National University of Singapore freeware winnv, winvat, winsd (can anyone tell me anything about the quality/useability of these?) Are there others? Any information would be greatly appreciated. Thanks a lot. joe -- Joe Pallas Apple Computer, Advanced Technology Group, Lab X From rem-conf-request@es.net Fri Feb 16 04:34:17 1996 Received: from upeksa.sdsc.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 16 Feb 1996 01:33:46 -0800 Received: by upeksa.sdsc.edu id BAA01626; Fri, 16 Feb 1996 01:33:45 -0800 From: kc@upeksa.sdsc.edu (k claffy) Message-Id: <199602160933.BAA01626@upeksa.sdsc.edu> Subject: ISMA (NSF workshop on Internet statistics measurement and analysis) 19-20 feb 1996 To: rem-conf@es.net Date: Fri, 16 Feb 1996 01:33:45 -0800 (PST) Cc: isma@kasina.nlanr.net X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Content-Type: text Content-Length: 464 We hope to multicast the NSF-sponsored workshop on Internet statistics, measurement and analysis, to take place february 19 and 20th [1.5 days] at SDSC. http://www.nlanr.net/ISMAwksp has the agenda and other info. [meeting is from 0830-1730 pacific time thursday feb 19 and 0830-1300 pacific friday feb 20] we'll announce the (audio/video/wb) sessions in sd as 'NSF stat workshop'. please let us know if there are any problems/ conflicts. tnx kc@nlanr.net From rem-conf-request@es.net Fri Feb 16 08:39:06 1996 Received: from BBN.COM (actually 128.89.0.122) by osi-west.es.net with ESnet SMTP (PP); Fri, 16 Feb 1996 05:38:35 -0800 Received: from WOOLSEY.BBN.COM by BBN.COM id aa10464; 16 Feb 96 8:28 EST Received: by woolsey.bbn.com.cnm (5.x/SMI-SVR4) id AA00375; Fri, 16 Feb 1996 08:28:53 -0500 Date: Fri, 16 Feb 1996 08:28:53 -0500 Message-Id: <9602161328.AA00375@woolsey.bbn.com.cnm> From: Linsey O'Brien To: spagnolo@nrnsinc.on.ca Cc: rem-conf@es.net, spagnolo@feline.nrnsinc.on.ca In-Reply-To: <199602152208.RAA09187@feline.nrnsinc.on.ca> (message from Joe Spagnolo on Thu, 15 Feb 1996 17:08:33 -0500 (EST)) Subject: Re: vat v4.0a2 on Solaris 2.5 Reply-To: lbob@bbn.com > > vat: "vat_main": bad option "colormodel": must be appname > Either someone slipped a new Tcl/tk version in (7.4/4.0 or later) or an old vat Tcl script in. That's one of the incompatibility errors hit in going from tk 3.6 to tk 4.0 or 4.1 Linsey -- Linsey O'Brien BBN, Inc., 6/3B Internet: lbob@bbn.com 10 Moulton St. Voice: (617) 873-3765 Cambridge, MA 02140 From rem-conf-request@es.net Fri Feb 16 10:53:22 1996 Received: from RMAIL.urz.tu-dresden.de (actually 141.30.66.2) by osi-west.es.net with ESnet SMTP (PP); Fri, 16 Feb 1996 07:52:43 -0800 Received: from RNCMM1.urz.tu-dresden.de by RMAIL.urz.tu-dresden.de with SMTP (PP) id <07301-0@RMAIL.urz.tu-dresden.de>; Fri, 16 Feb 1996 16:47:02 +0100 Received: by rncmm1.urz.tu-dresden.de (5.0/SMI-SVR4) id AA02578; Fri, 16 Feb 1996 16:50:17 --100 From: mmt-ref@rmail.urz.tu-dresden.de (Multimedia Referenzzentrum) Message-Id: <9602161550.AA02578@rncmm1.urz.tu-dresden.de> Subject: Conference announcement ICDP'96 To: rem-conf@es.net Date: Fri, 16 Feb 1996 16:50:16 +0100 (MET) Cc: mbone@ISI.EDU X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3635 Announcement ICDP96 - IFIP/IEEE Int. Conference on Distributed Platforms Client/Server and Beyond: DCE, CORBA, ODP & Advanced Distributed Applications Dresden, Germany February 27 - March 1, 1996 ========================================================================== OBJECTIVES AND SCOPE - ICDP '96 ------------------------------------------------------------------------ Client/Server applications are of increasing importance in industry, and have been enhanced with advanced distributed object-oriented techniques, dedicated tool support and both multimedia and mobile computing extensions. Such solutions are a significant step towards a global distributed processing model. Recent responses to this trend are standardized platforms and models including the Distributed Computing Environment (DCE) of the Open Software Foundation (OSF), Open Distributed Processing (ODP), and the Common Object Request Broker Architecture (CORBA) of the Object Management Group (OMG). ICDP'96 will be a major forum for distributed systems researchers, network developers, service providers, application designers and end users for discussing the latest research and development results with respect to these platforms. ------------------------------------------------------------------------ >From Wednesday, February 28 until Friday, March 1 we plan to transmit selected sessions of the ICDP'96. A detailed schedule and further information on the conference will be found at http://wwwrn.inf.tu-dresden.de/lsrn/icdp96.html The transmission will be announced in the sd tool. There will be seperate sessions for video, audio and whiteboard. As far as possible we try to put the slides into the wb. The following tools will be used: vat 3.4 with pcm2 encoding wb 1.58 vic 2.7 with h261 The vic 2.7 binaries are available from ftp.ee.lbl.gov in conferencing/vic/alpha-test. In a selected session (most likely the panel on "Distributed platforms: Impacts on the Infobahn" on Thursday 29th at 3.30 pm CET) it is planned to give MBoners the chance of asking questions. This depends heavily on the broadcast quality. Regards, Torsten Schulz & Johannes Kadura -- |------------------------------------------------------------------------------| | Referenzzentrum fuer multimediale Teledienste, TU Dresden | | | | Dr. Klaus Koehler Torsten Schulz Johannes Kadura | | | | Postanschrift: | | M M M M RRRRR ZZZZZZ Universitaetsrechenzentrum | | MM MM MM MM R R Z Mommsenstrasse 13, D-01062 Dresden | | M M M M M M R R Z Tel.: +49 351 463-5653 | | M M M M RRRRR Z Fax: +49 351 463-7116 | | M M M M R R Z | | M M M M R R Z e-mail: mmt-ref@rmail.urz.tu-dresden.de | | M M M M R R ZZZZZZ WWW: http://www.tu-dresden.de/urz/mm.html | | Informations- und Diskussionsliste: | | mmt-liste@rmail.urz.tu-dresden.de | |------------------------------------------------------------------------------| From rem-conf-request@es.net Fri Feb 16 12:03:25 1996 Received: from cerc.wvu.edu (actually 157.182.44.3) by osi-west.es.net with ESnet SMTP (PP); Fri, 16 Feb 1996 09:03:00 -0800 Received: from elk (elk.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA16266; Fri, 16 Feb 96 12:02:56 EST Received: by elk (5.x//ident-1.0) id AA00393; Fri, 16 Feb 1996 12:02:54 -0500 Date: Fri, 16 Feb 1996 12:02:46 -0500 (EST) From: "Todd L. Montgomery" Subject: RMP FTP site To: RMP Discussion Mailing List Cc: rem-conf@es.net, Brian Whetten Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We had a drive crash on the RMP FTP site recently (really recently - within the last couple hours). So, temporarily, the last RMP release, 1.3 Beta, is only available through the following link: http://www.cerc.wvu.edu/~tmont/RMP.html The RMP specifications, documents, and previous releases are currently unavailable (or at least until we can replace the drive, restore backups, etc.). If someone desparately needs them, let me know and I will do my best. Hopefully, we will be back up in a week or so. :) I am sorry for any inconvenience..... -- Todd Montgomery tmont@cerc.wvu.edu From rem-conf-request@es.net Fri Feb 16 12:11:06 1996 Received: from upeksa.sdsc.edu (actually 198.17.46.55) by osi-west.es.net with ESnet SMTP (PP); Fri, 16 Feb 1996 09:10:34 -0800 Received: by upeksa.sdsc.edu id JAA02705; Fri, 16 Feb 1996 09:10:31 -0800 From: hwb@upeksa.sdsc.edu (Hans-Werner Braun) Message-Id: <199602161710.JAA02705@upeksa.sdsc.edu> Subject: lil' oops To: rem-conf@es.net Date: Fri, 16 Feb 1996 09:10:31 -0800 (PST) Cc: isma@kasina.nlanr.net X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Content-Type: text Content-Length: 738 That's *Monday* Feb 19. And Tue Feb20. Sorry. From: kc@upeksa.sdsc.edu (k claffy) Subject: ISMA (NSF workshop on Internet statistics measurement and analysis) 19- 20 feb 1996 To: rem-conf@es.net Date: Fri, 16 Feb 1996 01:33:45 -0800 (PST) Cc: isma@kasina.nlanr.net We hope to multicast the NSF-sponsored workshop on Internet statistics, measurement and analysis, to take place february 19 and 20th [1.5 days] at SDSC. http://www.nlanr.net/ISMAwksp has the agenda and other info. [meeting is from 0830-1730 pacific time thursday feb 19 and 0830-1300 pacific friday feb 20] we'll announce the (audio/video/wb) sessions in sd as 'NSF stat workshop'. please let us know if there are any problems/ conflicts. tnx kc@nlanr.net From rem-conf-request@es.net Fri Feb 16 12:43:46 1996 Received: from upeksa.sdsc.edu (actually 198.17.46.55) by osi-west.es.net with ESnet SMTP (PP); Fri, 16 Feb 1996 09:42:54 -0800 Received: by upeksa.sdsc.edu id JAA02899; Fri, 16 Feb 1996 09:42:51 -0800 From: kc@upeksa.sdsc.edu (k claffy) Message-Id: <199602161742.JAA02899@upeksa.sdsc.edu> Subject: ISMA (NSF workshop on Internet statistics measurement and analysis) (fwd) CORRECTION to TYPO in DATE To: rem-conf@es.net Date: Fri, 16 Feb 1996 09:42:51 -0800 (PST) Cc: isma@upeksa.sdsc.edu X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Content-Type: text Content-Length: 997 folks: should say monday and tuesday, feb 19-20 sorry k Forwarded message: From nobody Fri Feb 16 04:18:32 1996 From: kc (k claffy) Message-Id: <199602160933.BAA01626@upeksa.sdsc.edu> Subject: ISMA (NSF workshop on Internet statistics measurement and analysis) 19-20 feb 1996 To: rem-conf@es.net Date: Fri, 16 Feb 1996 01:33:45 -0800 (PST) Cc: isma@kasina.nlanr.net X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Content-Type: text Content-Length: 464 We hope to multicast the NSF-sponsored workshop on Internet statistics, measurement and analysis, to take place february 19 and 20th [1.5 days] at SDSC. http://www.nlanr.net/ISMAwksp has the agenda and other info. [meeting is from 0830-1730 pacific time thursday feb 19 and 0830-1300 pacific friday feb 20] we'll announce the (audio/video/wb) sessions in sd as 'NSF stat workshop'. please let us know if there are any problems/ conflicts. tnx kc@nlanr.net From rem-conf-request@es.net Sat Feb 17 00:42:12 1996 Received: from bh.kyungpook.ac.kr by osi-west.es.net with ESnet SMTP (PP); Fri, 16 Feb 1996 21:41:37 -0800 Received: from palgong.kyungpook.ac.kr (palgong.kyungpook.ac.kr [155.230.12.2]) by bh.kyungpook.ac.kr (8.6.12H1/8.6.9) with ESMTP id OAA25441 for ; Sat, 17 Feb 1996 14:33:48 +0900 Received: by palgong.kyungpook.ac.kr (8.6.12H1/8.6.9) id OAA22677; Sat, 17 Feb 1996 14:36:12 +0900 Date: Sat, 17 Feb 1996 14:36:12 +0900 From: hsj@palgong.kyungpook.ac.kr (Sang-Jin Her) Message-Id: <199602170536.OAA22677@palgong.kyungpook.ac.kr> To: rem-conf@es.net Content-Length: 79 Subscribe IETF Remote Conference hsj@palgong.kyungpook.ac.kr ( Sang-Jin Hur ) From rem-conf-request@es.net Sat Feb 17 12:33:40 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Sat, 17 Feb 1996 09:33:11 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 17 Feb 1996 17:32:56 +0000 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: Gary Veum , rem-conf@es.net Subject: Re: wb on solaris 2.5? In-reply-to: Your message of "Thu, 08 Feb 1996 15:20:18 GMT." Date: Sat, 17 Feb 1996 17:32:55 +0000 Message-ID: <3198.824578375@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >On Thu, 8 Feb 1996, Gary Veum wrote: > >> I apologize if this topic has been discussed, but I didn't know there >> was a problem until recently with it. >> >> On 2.5, wb works in readonly mode. When write access is enabled, it crashes >> with a seg fault. >> >> I've been told that these are running in compatibility mode (only sunos >> binaries are being distributed of wb). It appears as though the compatibili >> isn't quite as good in 2.5 as it was in 2.4. >> >> So, does someone have a wb that works on 2.5? This seems to be an Xresources problem which appears (at least to me) to only happen with CDE on solaris 2.5. A simple but horrible work around is the following script (where real-wb is the name of your wb binary). Mark #!/bin/sh xrdb -query > /tmp/${USER}${DISPLAY}xrdb xrdb -remove real-wb $* & sleep 10 xrdb -load /tmp/${USER}${DISPLAY}xrdb From rem-conf-request@es.net Tue Feb 20 19:53:59 1996 Received: from plateau.cs.Berkeley.EDU (actually bugs-bunny.CS.Berkeley.EDU) by osi-west.es.net with ESnet SMTP (PP); Tue, 20 Feb 1996 16:53:26 -0800 Received: from garfield.CS.Berkeley.EDU (garfield.CS.Berkeley.EDU [128.32.32.118]) by plateau.cs.Berkeley.EDU (8.6.11/8.3) with ESMTP id QAA21621; Tue, 20 Feb 1996 16:45:07 -0800 Received: from garfield.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by garfield.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id QAA11261; Tue, 20 Feb 1996 16:48:29 -0800 Message-Id: <199602210048.QAA11261@garfield.CS.Berkeley.EDU> From: Andrew Swan To: 298@bugs-bunny.CS.Berkeley.EDU cc: rowe@cs.berkeley.edu Subject: UC Berkeley Multimedia Seminar 2/21/96 - "Cable Modems and their Impact on delivering Internet to the Home" X-URL: http://www.cs.berkeley.edu/~aswan/ Date: Tue, 20 Feb 1996 16:48:29 -0800 Sender: aswan@bugs-bunny.CS.Berkeley.EDU The fifth Berkeley Multimedia and Graphics seminar of the Spring 1996 semester will be held Wednesday, February 21 from 12:30 - 2:00 PST in 405 Soda Hall. The speaker will be Mark Laubach of Com21, discussing "Cable Modems and their Impact of delivering Internet to the Home." The talk will be broadcast on the Internet MBONE, beginning at roughly 12:40 PM PST. Please note that you will need vic 2.7 to watch the broadcast. Pre-compiled vic binaries for most architectures are available from: ftp://ftp.ee.lbl.gov/conferencing/vic/alpha-test/ We also hope to broadcast the seminar on the BAGNet -- an sd advertisement should appear by the time the seminar starts. Questions should be directed to Larry Rowe (rowe@cs.berkeley.edu) Abstract: Cable modem technology is rapidly entering commonplace discussion. The capabilities provided by cable modems promise data bandwidth speeds far in excess of those provided by traditional twisted pair public telephone networks. Internet service providers are taking position to promote this next generation method of delivering Internet services to the home as part of the broadband access to the home race. Cable TV operators and Regional Bell Operating Companies (RBOCs), e.g. PacBell, are preparing for this integrated broadband future by installing or rebuilding existing all-coaxial cable plants into two-way Hybrid-Fiber Coaxial plants and by offering a wide range of both data and nteractive services which they feel will be most attractive to their subscriber base. Initially these services will only provide Internet access and access to the major information service (e.g., Compuserve, AOL, and Prodigy). These service offerings will quickly advance to support multi-player gaming and collaborative services such as voice and desktop video teleconferencing. As an introduction to some of the issues surrounding cable modem technology, this presentation summarizes two of the standardization efforts: the ATM over HFC definition work taking place in the ATM Forum's Residential Broadband Working Group and the standards progress in the IEEE P802.14 Cable TV Media Access Control and Physical Protocol Working Group. Delivering a viable Internet service to a Cable TV based subscriber community has its own set of deployment issues that are briefly overviewed and summarized. -- Andrew Swan aswan@cs.berkeley.edu Plateau Multimedia Research Group http://www.cs.berkeley.edu/~aswan/ From rem-conf-request@es.net Wed Feb 21 03:55:19 1996 Received: from milou.comp.lancs.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 21 Feb 1996 00:54:33 -0800 Received: from tina.comp.lancs.ac.uk by milou.comp.lancs.ac.uk; Wed, 21 Feb 1996 08:52:36 GMT From: Randa Message-Id: <25713.199602210854@tina.comp.lancs.ac.uk> Received: by tina.comp.lancs.ac.uk; Wed, 21 Feb 1996 08:54:22 GMT Subject: H/w questions To: rem-conf@es.net Date: Wed, 21 Feb 1996 08:54:22 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I am starting a project to send video and audio using RTP. I have several questions mainly regarding the equipment: - We have Sun Sparc 5.5 m/c which has Sun Video Sbus Card. I know that this does the h/w MPEG1 compression only. So, there is no way to decompress on Sun m/c using hardware MPEG decompression? - Does SunVideo Card have to be installed with sxgraphics card to function properly? - What speed of m/c you advise by so that there won't be lots of time wasted in processing like decoding for example - Also, we have Berkely decoding software. I do not Know if there is better decoding method and do I have to do some conversion to the format of the frame output from the decoder to be displayed displayed using X. -Also, for the camera to be hooked to the SunVideo Card, does it have to be SunCamera? If not, what is a good price Camera I can get? - Also,I want to know the sites where I can get the source code of nv, vat,vic, nevot, and bat. Do all of them have adaptive playback or only nv? Thanks randa@comp.lancs.ac.uk From rem-conf-request@es.net Wed Feb 21 05:24:16 1996 Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Wed, 21 Feb 1996 02:23:44 -0800 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id LAA18663 (8.7.2/7.5a-FAU);; Wed, 21 Feb 1996 11:23:39 +0100 (MET) From: Toerless Eckert Message-Id: <199602211023.LAA18663@faui40.informatik.uni-erlangen.de> Subject: Re: H/w questions To: randa@comp.lancs.ac.uk (Randa) Date: Wed, 21 Feb 1996 11:23:37 +0100 (MET) Cc: rem-conf@es.net In-Reply-To: <25713.199602210854@tina.comp.lancs.ac.uk> from "Randa" at Feb 21, 96 08:54:22 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > - We have Sun Sparc 5.5 m/c which has Sun Video Sbus Card. I know that this > does the h/w MPEG1 compression only. So, there is no way to decompress on > Sun m/c using hardware MPEG decompression? Right now i know of no i/o card that does hardware mpeg1 decode for sun/sparc. iSupposedly Parallax will have a mpeg2 decoder board ?by the end of the year?, and probably other companies too. > - Does SunVideo Card have to be installed with sxgraphics card to > function properly? No. 24 Bit Graphics is just nicer to have than 8 bit. > - What speed of m/c you advise by so that there won't be lots of time > wasted in processing like decoding for example Depends only on your CPU. Anywhere from 5 frams to full framerate with current suns. > - Also, we have Berkely decoding software. I do not Know if there is better > decoding method and do I have to do some conversion to the format of the frame output from the decoder to be displayed displayed using X. Better decoding than what ? There are many different mpeg decoder implementations for sun. As far as i remember, the berkeley decoder already does dithering. > -Also, for the camera to be hooked to the SunVideo Card, does it have to be > SunCamera? If not, what is a good price Camera I can get? What do you want the camera for ? > - Also,I want to know the sites where I can get the source code of nv, vat,vic, nevot, and bat. Do all of them have adaptive playback or only nv? Look on the web pages of your national mice support center, it's, uugh... Someone from the UK please ? From rem-conf-request@es.net Wed Feb 21 07:35:36 1996 Received: from cancer.ucs.ed.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 21 Feb 1996 04:34:56 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with ESMTP id MAA27564; Wed, 21 Feb 1996 12:34:49 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id MAA19797; Wed, 21 Feb 1996 12:34:44 GMT Date: Wed, 21 Feb 1996 12:34:43 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Toerless Eckert cc: Randa , rem-conf@es.net Subject: Re: H/w questions In-Reply-To: <199602211023.LAA18663@faui40.informatik.uni-erlangen.de> Message-ID: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-URL: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 21 Feb 1996, Toerless Eckert wrote: > Look on the web pages of your national mice support center, it's, uugh... > Someone from the UK please ? For Lancaster (and everyone else in England) it is: http://www-mice-nsc.cs.ucl.ac.uk/mice-nsc/ for Scotland: http://mice.ed.ac.uk/mice/ for Wales: http://www.aber.ac.uk/~dcswww/Public/Research/Telematics/MICE/index.html Northern Ireland has yet to be announced. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Wed Feb 21 08:24:43 1996 Received: from fenris.hiof.no by osi-west.es.net with ESnet SMTP (PP); Wed, 21 Feb 1996 05:24:07 -0800 Received: from gyda.hiof.no by fenris.hiof.no with SMTP (PP) id <11638-0@fenris.hiof.no>; Wed, 21 Feb 1996 14:23:48 +0100 Date: Wed, 21 Feb 1996 14:23:47 +0100 (MET) From: "Halvor Kise jr." X-Sender: halvork@gyda To: Toerless Eckert cc: Randa , rem-conf@es.net Subject: Re: H/w questions In-Reply-To: <199602211023.LAA18663@faui40.informatik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 21 Feb 1996, Toerless Eckert wrote: > > - Also,I want to know the sites where I can get the source code of nv, vat,vic, nevot, and bat. Do all of them have adaptive playback or only nv? > > Look on the web pages of your national mice support center, it's, uugh... > Someone from the UK please ? The URL is: http://www-mice-nsc.cs.ucl.ac.uk/mice-nsc/ - Halvor. -- *** MEMENTO MORI *** PGP-key by fingering halvork@frodo.hiof.no http://www.hiof.no/~halvork/ From rem-conf-request@es.net Wed Feb 21 11:25:48 1996 Received: from nren-vod.arc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Wed, 21 Feb 1996 08:25:11 -0800 Received: by nren-vod.arc.nasa.gov (940816.SGI.8.6.9/1.35) id IAA02502; Wed, 21 Feb 1996 08:25:09 -0800 Date: Wed, 21 Feb 1996 08:25:09 -0800 From: garyp@nren-vod.arc.nasa.gov (Gary Paden) Message-Id: <199602211625.IAA02502@nren-vod.arc.nasa.gov> To: rem-conf@es.net Subject: NASA Shuttle Broadcast Modification For the upcoming mbone presentation of the NASA Shuttle Mission a video format change has been made. We are now using VIC 2.7a with h.261 encoding. Please adjust your systems accordingly for proper viewing. Thannks for your support. Gary Paden NASA Ames/Sterling garyp@nren-vod.arc.nasa.gov (415)604-0082 From rem-conf-request@es.net Wed Feb 21 12:29:18 1996 Received: from rztsun3.rz.tu-harburg.de by osi-west.es.net with ESnet SMTP (PP); Wed, 21 Feb 1996 09:28:46 -0800 Message-Id: <199602211727.SAA17857@rztsun.rz.tu-harburg.de> Comments: Authenticated sender is From: t.hamann@tu-harburg.d400.de Organization: Technische Universitaet Hamburg-Harburg To: rem-conf@es.net Date: Wed, 21 Feb 1996 18:28:57 +1 Subject: Looking for a tunnel in Berkeley CC: dwinet@qal.berkeley.edu Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Hi... I am looking for a tunnel in the Berkeley area. We installed on our system at ICCF (qal.berkeley.edu) the M-Bone programs. We had a tunnel for a while, but now we are without a tunnel-provider. I've tried to get a tunnel but without any success. I hope someone can give as a feed. We just want to receive M-Bone transmissions. Regards Tilo Hamann David Winet ------------------------------------------------------------- >> Tilo Hamann << >> Technische Universitaet Hamburg-Harburg << >> E-Mail: t.hamann@tu-harburg.d400.de << >> exthaman@qal.berkeley.edu << >> << ------------------------------------------------------------- From rem-conf-request@es.net Wed Feb 21 14:16:17 1996 Received: from qucis.queensu.ca by osi-west.es.net with ESnet SMTP (PP); Wed, 21 Feb 1996 11:15:41 -0800 Received: from teaspoon.qucis.queensu.ca by qucis.queensu.ca (5.x/SMI-SVR4-qs1.6) id AA03046; Wed, 21 Feb 1996 14:15:27 -0500 Received: by teaspoon.qucis.queensu.ca (SMI-8.6/SMI-SVR4-qc1.3) id OAA04793; Wed, 21 Feb 1996 14:15:26 -0500 Date: Wed, 21 Feb 1996 14:15:24 -0500 (EST) From: Zhenjun Zhu X-Sender: zhuz@teaspoon To: rem-conf@es.net Subject: RTP C++ library implementation Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I understand someone asked the availability of C++ RTP library implementation before and was pointed to FAQ. There was indeed one pointer there pointing to fantoni@iasi.rm.cnr.it however I can not trace that person, neither can I find the source package from ftp://ftp.cnd.it/. I am wondering whether: (1) Someone can sent me the source if he/she has it, or (2) Some one can point me to somewhere else which has an RTP library implemented in C++. Thanks. ************************************************** Zhenjun Zhu Graduate Student Department of Computing and Information Science Queen's University, Kingston, Canada zhuz@qucis.queensu.ca ************************************************** From rem-conf-request@es.net Wed Feb 21 16:21:43 1996 Received: from dfw.dfw.net by osi-west.es.net with ESnet SMTP (PP); Wed, 21 Feb 1996 13:21:10 -0800 Received: by dfw.dfw.net (8.7.1/SMI-4.1) id PAA06687; Wed, 21 Feb 1996 15:17:39 -0600 (CST) Date: Wed, 21 Feb 1996 15:17:38 -0600 (CST) From: Aleph One To: rem-conf@es.net Subject: Tunnel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Looking for someone to provide a tunnel for cyberworks.net. Primary net connection is Net 99 at Los Angeles. If anyone is just a few hops away and is willing to provide a tunnel is would be greatly appreciated! Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 From rem-conf-request@es.net Wed Feb 21 16:27:15 1996 Received: from nahrstedt.cs.uiuc.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 21 Feb 1996 13:26:17 -0800 Received: (from klara@localhost) by nahrstedt.cs.uiuc.edu (8.7.1/8.7.1) id PAA04593; Wed, 21 Feb 1996 15:24:21 -0600 (CST) Date: Wed, 21 Feb 1996 15:24:21 -0600 (CST) From: Klara Nahrstedt Message-Id: <199602212124.PAA04593@nahrstedt.cs.uiuc.edu> To: rem-conf@es.net Subject: Call for Papers: HICSS-30 Cc: klara@cs.uiuc.edu _______________________________________________________________________ _______________________________________________________________________ Call For Papers Software Technology Track of the 30th Hawaii International Conference on System Sciences, HICSS-30 Maui, Hawaii - January 7-10, 1997 _______________________________________________________________________ _______________________________________________________________________ Authors are invited to submit papers describing the new advances in theory, design, implementation, use, application, and performance evaluation of high performance distributed systems. We welcome papers that may be theoretical, conceptual, tutorial, or descriptive in nature. The Software Technology Track consists of ten (10) minitracks that cover a broad selection of timely and important topics in the area of distributed systems. The specific topics and coordinators of the minitracks are listed at the end of this call. Individuals interested in refereeing papers should contact the minitrack coordinators directly. _______________________________________________________________________ Instructions for Authors ------------------------ Submit a 300-word abstract and then eight (8) copies of the manuscript to one of the minitrack coordinators according to their areas of responsibility by the given deadlines. Manuscripts should have an abstract and be 22-25 typewritten, double-spaced pages in length. Papers must not have been previously presented or published, nor currently submitted for journal publication. Each manuscript will be subjected to a rigorous refereeing process involving at least five reviewers. _______________________________________________________________________ Track Chairman -------------- Hesham El-Rewini Department of Computer Science University of Nebraska at Omaha Omaha, NE 68182 Phone: (402) 554-2852 Fax: (402) 554-2975 Email: rewini@cs.unomaha.edu _______________________________________________________________________ Track Advisory Committee ------------------------ o Gul Agha, University of Illinois, USA o Khalil M. Ahmed, University of Alexandria, EGYPT o Jim Anderson, University of North Carolina, USA o Jim Costa, Sandia National Laboratories, USA o Karsten M. Decker, Swiss Scientific Computing Center, SWITZERLAND o Alois Ferscha, Universitaet Wien, AUSTRIA o Apostolos Gerasoulis, Rutgers University, USA o Wolfgang A. Halang, Fernuniversitaet, GERMANY o Alexey Lastovetsky, Institute for System Programming, RUSSIA o Thomson Leighton, MIT, USA o Sartaj Sahni, University of Florida, USA o Alok Sinha, Microsoft, USA o Pradip Srimani, Colorado State University, USA o Ivan Stojmenovic, University of Ottawa, CANADA o Caetano Traina Junior, University of Sao Paulo, BRAZIL o Peter Wegner, Brown University, USA o Chung-Kwong Yuen, National University of Singapore, SINGAPORE o Albert Y. Zomaya, The University of Western Australia, AUSTRALIA _______________________________________________________________________ 1996 Deadlines -------------- o A 300-word abstract by March 15 o Feedback to author on abstract by April 15 o Eight copies of the manuscript by June 1 o Notification of accepted papers by August 31 o Camera-ready copies of accepted manuscripts are due by October 1 _______________________________________________________________________ Tutorials --------- Tutorials will be offered on Tuesday, January 7, 1997. Interested speakers should submit full-day or half-day proposals to the track chairman by March 15, 1996. _______________________________________________________________________ HICSS Information ----------------- http://www.cba.hawaii.edu/hicss _______________________________________________________________________ Topics and Coordinators of the Minitracks ----------------------------------------- 1) OBJECT-ORIENTED METHODS FOR DISTRIBUTED APPLICATIONS Object-oriented modeling of high-performance distributed systems, designing distributed object systems using CORBA or COM, experience of applying object-oriented methods to distributed systems, integrating object-oriented techniques with formal validation and verification techniques, object-oriented design patterns for distributed systems. COORDINATORS ------------ Ian Gorton, iango@syd.dit.csiro.au CSIRO Division of Information Technology Locked Bag 17, North Ryde, Sydney NSW 2113, AUSTRALIA Innes Jelly, i.e.jelly@shu.ac.uk School of Computing and Management Sciences Sheffield Hallam University, Sheffield S11 8HD, UK Peter Croll, prc@dcs.shef.ac.uk Dept. of Computer Science University of Sheffield Sheffield, S1 4DP, UK Guido Wirtz, guidow@math.uni-muenster.de Institut fuer Informatik, Fachbereich Mathematik, Westfaelische Wilhelms-Universitaet Muenster, Einsteinstrasse 62, D-48149 Muenster, GERMANY _______________________________________________________________________ 2) DISTRIBUTED OBJECTS PLATFORMS Comparison of object-based distributed systems, compatibility issues and emerging object standards: OLE, CORBA, OODCE, etc., distributed objects over the web, distributed object services: security, trading, transactions, replication, etc., performance evaluation, experiences, implementation issues. COORDINATORS ------------ Rachid Guerraoui, guerraoui@lse.epfl.ch DI-LSE EPFL IN-Ecublens 1015 Lausanne Switzerland Steve Vinoski, vinoski@ch.hp.com Hewlett-Packard, MS CHR-03-DW 300 Apollo Drive Chelmsford, MA 01824 _______________________________________________________________________ 3) PARALLEL AND DISTRIBUTED ALGORITHMS Design and analysis of parallel and distributed algorithms in: graph theory, image processing, computational geometry, networks and combinatorics, applications and cost models. COORDINATORS ------------ Michael A. Langston, langston@cs.utk.edu Department of Computer Science University of Tennessee Knoxville, TN 37996-1301 Stephan Olariu, olariu@cs.odu.edu Department of Computer Science Old Dominion University Norfolk, VA 23529-0162 James. L. Schwing, schwing@cs.odu.edu Department of Computer Science Old Dominion University Norfolk, VA 23529-0162 _______________________________________________________________________ 4) MULTI-THREADED SYSTEMS Programming languages for multi-threaded systems, analytical performance models, empirical performance studies, multiple context processors, interleaving of multiple threads, cache memory designs, fine-grained and coarse grained multithreading, runtime and kernel support for multithreading. COORDINATORS ------------ Krishna Kavi, kavi@cse.uta.edu Department of Computer Science Engineering University of Texas at Arlington Arlington, TX 76019-0015 A.R. Hurson, a2h@ecl.psu.edu Dept. of ECE The Pennsylvania State University University Park, PA 16802 _______________________________________________________________________ 5) COORDINATION LANGUAGES, MODELS, SYSTEMS Models, languages and mechanisms for coordination, operating system and middleware support for coordination, compiling techniques and semantic issues for coordination languages, coordination in software architecture design, case studies with industrial relevance. COORDINATOR ----------- Paolo Ciancarini, cianca@cs.unibo.it Dept. of Computer Science, Univ. of Bologna Pza. di Porta S.Donato, 5, 40127 Bologna, ITALY _______________________________________________________________________ 6) SOFTWARE ENGINEERING FOR DISTRIBUTED SYSTEMS Development methodologies for distributed software systems, specification, verification and validation, application of formal methods, prototyping, testing, and performance measurement, impact of distributed or parallel languages and architectures on development techniques, CASE tools and run-time support environments, problems encountered in industrial systems, software reuse. Patrick Nixon, Paddy.Nixon@cs.tcd.ie Dept. of Computer Science Trinity College, University of Dublin, IRELAND Vinny Cahill, Vinny.Cahill@dsg.cs.tcd.ie Dept. of Computer Science Trinity College University of Dublin, IRELAND Fethi Rabhi, F.A.Rabhi@dcs.hull.ac.uk Parallel Processing Group University of Hull, Hull, UK _______________________________________________________________________ 7) DISTRIBUTED PERSISTENT ARCHITECTURES Models of distribution in persistent systems, resilience in distributed persistent systems, replication in persistent systems, protection in distributed persistent systems, concurrency control for persistent systems,garbage collection in distributed persistent systems, and experiences with distributed persistent applications. COORDINATORS ------------ John Rosenberg, johnr@cs.usyd.edu.au Basser Department of Computer Science University of Sydney New South Wales 2006, AUSTRALIA Alan Dearle, al@cs.stir.ac.uk Department of Computer Science University of Stirling FK9 4LA, SCOTLAND Richard Connor, richard@dcs.st-and.ac.uk Department of Mathematical and Computational Science University of St Andrews St Andrews, KY10 0DR _______________________________________________________________________ 8) PARTITIONING AND SCHEDULING Static and dynamic scheduling, partitioning schemes, load balancing, performance and benchmarking, impact of granularity, heterogeneous systems and clusters, decomposition of mathematical and engineering applications, tools, compilers for task clustering and scheduling. COORDINATORS ------------ Ishfaq Ahmad, iahmad@cs.ust.hk Dept. of Computer Science Hong Kong University of Science and Technology Clear Water Bay, Kowloon, HONG KONG Sekhar Darbha, darbha@ece.rutgers.edu Department of Electrical and Computer Engineering Rutgers University Piscataway, NJ 08855-0909. _______________________________________________________________________ 9) DISTRIBUTED VIRTUAL REALITY ENVIRONMENTS Virtual world representation, distributed modeling and simulation, multimedia data processing, networking issues, communication issues, user interface, performance evaluation. COORDINATOR ----------- Guenter Haring, haring@ani.univie.ac.at Institut Fuer Angewandte Informatik Universitaet Wien, Lanaugasse 2/8 A-1080 Vienna, AUSTRIA _______________________________________________________________________ 10) DISTRIBUTED MULTIMEDIA AND COLLABORATION OVER THE WEB http://nahrstedt.cs.uiuc.edu:5000/pub/HICSS-MM.html OS support for resource admission, allocation and scheduling, media and clock synchronization, networking architectures and protocols, static/dynamic load management strategies, distributed multimedia applications, web-based collaborative applications, support for collaboration over the web, support for security and privacy, scalability, concurrency control, floor control, access control, etc. COORDINATORS ------------ Atul Prakash, aprakash@eecs.umich.edu Department of EECS, University of Michigan, Ann Arbor 48109-2122 Nalini Venkatasubramanian, nalini@gaia.hpl.hp.com Hewlett-Packard Laboratories 1501 Page Mill Road, MS 1U-17 Palo Alto CA 94304 Klara Nahrstedt, klara@cs.uiuc.edu Dept. of Computer Science 3111 Digital Computer Laboratory 1304 West Springfield Ave. Urbana IL 61801 _______________________________________________________________________ From rem-conf-request@es.net Wed Feb 21 16:55:28 1996 Received: from rags.rutgers.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 21 Feb 1996 13:54:04 -0800 Received: (from badri@localhost) by rags.rutgers.edu (8.6.12+bestmx+oldruq+newsunq/8.6.12) id QAA27178 for rem-conf@es.net; Wed, 21 Feb 1996 16:53:51 -0500 Date: Wed, 21 Feb 1996 16:53:51 -0500 From: Br Badrinath Message-Id: <199602212153.QAA27178@rags.rutgers.edu> To: rem-conf@es.net Subject: Call for papers, Mobicom96 ------------------------------------------------------------------ | SECOND ACM INTERNATIONAL CONFERENCE | | ON | | MOBILE COMPUTING AND NETWORKING 1996 | | | | (ACM MobiCom'96) | | | | November 11-12, 1996 (Tutorials on Sunday, November 10, 1996 | | Rye Hilton, Rye, New York, USA | | | | Sponsored by: | | | | ACM CESDIS NASA IEEE | | Sigcomm, Sigmetrics, ComSoc | | Sigops, Sigact | ------------------------------------------------------------------ The wireless communication revolution is bringing fundamental changes to telecommunication and computing. Wide-area cellular systems and wireless LANs promise to make integrated networks a reality and provide fully distributed and ubiquitous mobile computing and communications, thus bringing an end to the tyranny of geography. Furthermore, services for the mobile user are maturing and are poised to change the nature and scope of communication. This conference, the second of an annual series, serves as the premier international forum addressing networks, systems, algorithms, and applications that support the symbiosis of portable computers and wireless networks. PAPERS Technical papers describing previously unpublished, original, completed, and not currently under review by another conference or journal are solicited on topics at the link layer and above. Topics will include, but are not limited to: * Applications and computing services supporting the mobile user. * Network architectures, protocols or service algorithms to cope with mobility, limited bandwidth, or intermittent connectivity. * Design and analysis of algorithms for online and mobile environments. * Mobile network protocols * Performance characterization of mobile/wireless networks and systems. * Network management for mobile and wireless networks. * Data management in mobile computing * Service integration and interworking of wired and wireless networks. * Characterization of the influence of lower layers on the design and performance of higher layers. * Security, scalability and reliability issues for mobile/wireless systems * Mobile computing * Mobile agents * Power management * Wireless multimedia systems * Satellite communication * Location-dependent applications * Distributed system aspects of mobile systems * Adaptive applications interfaces suitable for mobile systems * Architectures of wireless and mobile networks and systems * Traffic integration for mobile applications All papers will be refereed by the program committee. Accepted papers will be published in conference proceedings. Papers of particular merit will be selected for publication in the ACM/Baltzer Journal on Wireless Networks and the ACM/Baltzer Mobile Networks & Nomadic Applications Journal. HOW TO SUBMIT Paper submission will be handled electronically. Authors should Email a PostScript version of their full paper to: mobicom96@gucci.mirc.gatech.edu This Email address will become operational on March 1, 1996. In order to print the PS versions of the papers, authors should ensure that their papers meet these restrictions: - PostScript version 2 or later - no longer than 15 pages - fits properly on "US Letter" size paper (8.5x11 inches) - reference only Computer Modern or standard Adobe fonts (i.e., Courier, Times Roman, or Helvetica); other fonts may be used but must be included in the PostScript file In addition, authors should separately Email the title, author names, full address and abstract of their paper to the program chairs. All submitted papers will be judged based on their quality through double-blind reviewing where the identities of the authors are withheld from the reviewers. Authors' names should not appear on the paper or in the postscript file. TUTORIALS Proposals for tutorials are solicited. Evaluation of the proposals will be based on expertise and experience of instructors, and the relevance of the subject matter. Potential instructors are requested to submit at most 5 pages, including a biographical sketch to Arvind Krishna (krishna@watson.ibm.com). PANELS Panels are solicited that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed more than 3 pages, including biographical sketches of the panelist. Potential panel organizers should contact Tom LaPorta (tlp@boole.att.com). STUDENT PARTICIPATION Papers with a student as a primary author will enter a student paper award competition. The student will receive a cash award of $500,- US Dollars. A cover letter must identify the paper as a candidate for the student paper competition. IMPORTANT DATES Submissions due: May 1, 1996 Notification of acceptance: July 15, 1996 Camera-ready version due: August 31, 1996 For More Information: Please contact Ian F. Akyildiz (ian@ee.gatech.edu) or Zygmunt J. Haas (zjh1@cornell.edu), the Program Co-Chairs. WWW/GOPHER INFORMATION This CFP and other ACM related activities may be found in http://info.acm.org/sigcomm/mobicom96 (for WWW browsers) +-------------------------------------------------------------------------+ GENERAL CO-CHAIRS: HAMID AHMADI RANDY KATZ IBM T. J. Watson Research Center Computer Science Division Room H3-C04 EECS Department P. O. Box 704 University of California Yorktown Heights, NY 10598 Berkeley, CA 94720-1776 Tel: 914-784-7219 Tel.: 510-642-8778 Fax: 914-784-6205 Fax.: 510-642-5775 Email: hamid@watson.ibm.com Email: randy@cs.Berkeley.edu PROGRAM CO-CHAIRS IAN F. AKYILDIZ ZYGMUNT J. HAAS School of ECE School of Electrical Engineering Georgia Tech Cornell University Atlanta, GA, 30332 Ithaca, N.Y. 14853 Tel.: 404-894-5141 Tel.: 607-255-3454 Fax.: 404-894-5028 Fax.: 607-255-9072 Email: ian@ee.gatech.edu Email: zjh1@cornell.edu TUTORIAL CHAIR LOCAL CHAIR ARVIND KRISHNA BOB FLYNN, Polytechnic University IBM T.J. Watson Research Center P.O. Box 704, H3-D32 VICE CHAIR Yorktown Heights, NY 10598 TOM LaPORTA, AT&T Bell Labs Tel.: (914) 784-7965 Fax.: (914) 784-6205 PUBLICITY CHAIR Email: krishna@watson.ibm.com B.R. BADRINATH, Rutgers Univ. TREASURER STEERING COMMITTEE CHAIR RAVI JAIN, Bellcore IMRICH CHLAMTAC, Boston Univ. PROGRAM COMMITTEE Rafael Alonso, Matsushita Labs Victor Bahl, DEC Brian Bershad, U. of Washington Ramon Caceres, AT&T Imrich Chlamtac, Boston U. Tony Dahbura, Motorola John Daigle, U. of Mississippi Maurizio Decina, CEFRIEL JJ Garcia Luna, UC Santa Cruz Mario Gerla, UCLA Peter Honeyman, U. of Michigan Pierre Humblet, Eurecom Tomasz Imielinski, Rutgers U. David Johnson, CMU Phil Karn, Qualcomm Mark Karol, AT&T Jay Kistler, DEC Barry Leiner, ARPA Jason Ying Bin Lin, NCTU Teresa Meng, Stanford U. Mahmoud Naghshineh, IBM TJ Peter O'Reilly, GTE Labs Charlie Perkins, IBM TJ Ray Pickholtz, GWU Dhiraj Pradhan, Texas A&M Chris Rose, Rutgers U. Krishan Sabnani, AT&T Mischa Schwartz, Columbia U. Martha Steenstrup, BBN Gordon Stuber, GaTech David Tennenhouse, MIT Marvin Theimer, XEROX Mehmet Ulema, Bellcore Newman Wilson, D. Sarnoff RC Parviz Yegani, Qualcomm From rem-conf-request@es.net Wed Feb 21 19:33:02 1996 Received: from tenet.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Wed, 21 Feb 1996 16:32:11 -0800 Received: from premise.CS.Berkeley.EDU (premise.CS.Berkeley.EDU [128.32.33.172]) by tenet.CS.Berkeley.EDU (8.6.11/8.6.6) with ESMTP id QAA26440; Wed, 21 Feb 1996 16:31:32 -0800 Received: from premise.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by premise.CS.Berkeley.EDU (8.6.11/1.3-tenet) with ESMTP id QAA16693; Wed, 21 Feb 1996 16:31:31 -0800 Message-Id: <199602220031.QAA16693@premise.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.5 12/11/95 To: t.hamann@tu-harburg.d400.de cc: rem-conf@es.net, dwinet@qal.berkeley.edu Subject: Re: Looking for a tunnel in Berkeley In-reply-to: Your message of "Wed, 21 Feb 1996 18:28:57." <199602211727.SAA17857@rztsun.rz.tu-harburg.de> From: bmah@cs.berkeley.edu (Bruce A. Mah) Reply-to: bmah@cs.berkeley.edu X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Feb 1996 16:31:24 -0800 Sender: bmah@tenet.CS.Berkeley.EDU t.hamann@tu-harburg.d400.de writes: > I am looking for a tunnel in the Berkeley area. We installed > on our system at ICCF (qal.berkeley.edu) the M-Bone programs. > We had a tunnel for a while, but now we are without a > tunnel-provider. Uhhh...you're *on* the UC Berkeley campus net and you're having problems getting an IP multicast feed? A lot of our subnets are IP multicast-capable...send mail to Rob Robertson to see about getting a feed for your subnet. There shouldn't be a need for a tunnel >from outside. Bruce Mah UC Berkeley Computer Science. From rem-conf-request@es.net Thu Feb 22 03:02:42 1996 Received: from ibminet.awdpa.ibm.com by osi-west.es.net with ESnet SMTP (PP); Thu, 22 Feb 1996 00:01:03 -0800 Received: by ibminet.awdpa.ibm.com (5.61/1.15) id AA27342; Thu, 22 Feb 96 00:18:54 -0800 Received: by ibmpa.awdpa.ibm.com (5.65b(em1)/2.06) id AA27094; Wed, 21 Feb 96 23:59:38 -0800 Received: from cs.nps.navy.mil by ibminet.awdpa.ibm.com (5.61/1.15) id AA27325; Thu, 22 Feb 96 00:16:35 -0800 Received: from trouble.cs.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1) id AA03912; Wed, 21 Feb 96 22:56:38 PST Received: by trouble.cs.nps.navy.mil (950215.SGI.8.6.10) id WAA27555; Wed, 21 Feb 1996 22:56:36 -0800 From: Your VE info source Message-Id: <9602212256.ZM27553@trouble.cs.nps.navy.mil> Date: Wed, 21 Feb 1996 22:56:36 -0800 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: rem-conf%es.net@ibmpa.awdpa.ibm.com Subject: Latest InfoBahn Calls for Participation: VRST '96 Call 1 March 96 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii The following are some of the latest Infobahn Calls for Participation: --> Virtual Reality Software and Technology 1996 - VRST '96 --> Call date: 1 March 1996 ----------------------------------------------------------------------- Call for Participation - VRST'96 ACM Symposium on Virtual Reality Software and Technology 1996 University of Hong Kong, Hong Kong - July 1-4, 1996 Sponsored by: ACM SIGCHI and SIGGRAPH PAPERS DUE MARCH 1, 1996 NEW! Short Papers: Got a new idea? Have a result that's too short for a full paper? Why not consider submitting a short paper to VRST'96. Short papers are printed in the proceedings and presented at the conference. A short paper is at most 2 pages in the conference proceedings (two columned, single spaced, 10 point type), and are reviewed using the same process as full papers. Send 5 copies of your short paper to one of the program co- chairs by March 1 1996. The ACM Symposium on Virtual Reality Software and Technology (VRST) is a major international conference on the technical aspects of virtual reality. This is the third VRST conference, with previous conferences held in Singapore and Japan. VRST's technical program includes papers, panels, tutorials and demonstrations of the latest VR technology and applications. It attracts a wide range of international attendees, providing an excellent opportunity to sample state of the art research from many international VR research centers, and interact with researchers >from around the world. Papers from previous VRST conferences have been published in ACM Transactions on Human-Computer Interaction (vol. 2, no. 3), and the May 1996 issue of the Communications of the ACM. In addition, VRST'96 provides an excellent opportunity to visit Hong Kong and other parts of Asia. Call for Papers VRST offers a high quality technical program, with papers reviewed by an international program committee. The proceedings for VRST'96 will be published by ACM, and will be available internationally after the conference through ACM and its agents. Papers are solicited on all technical aspects of virtual reality and related technologies, including, but not limited to, the following topics: Input Devices Haptic Feedback Geometrical Modeling Animation Distributed Environments Simulation Time Critical Rendering 3D Interaction Techniques VR Software Environment Design Collision Detection Games and Entertainment Applications of VR Output devices Five copies of technical papers must be sent to one of the program co-chairs by March 1, 1996. Authors of accepted papers will be notified in April, and final camera ready copy will be required by the middle of May. All papers must have a cover letter containing the name and address of the contact author, along with email address, office phone and FAX number. Papers must be sent by regular mail or courier, papers sent by FAX or electronically won't be accepted. Send papers to one of the following addresses: Michael Zyda Kim Fairchild Naval Postgraduate School Institute of System's Science Code CS/Zk, Dept. of Computer Science National University of Singapore Spanagel Hall 252 Heng Mui Keng Terrace, Kent Ridge Monterey, California 93943-5118 Singapore 0511 zyda@siggraph.org fair@iss.nus.sg Call for Tutorials The first day of VRST is devoted to full and half day tutorials. Proposals for tutorials on topics related to virtual reality and interactive 3D computer graphics should be sent to the General Chair at the address listed below by March 1, 1996. Proposals should include the title of the tutorial, a short description of the tutorial suitable for publication in the final program, a list of topics covered, AV and computer requirements, and a list of presenters with short biographical sketches. The cover letter submitted with the tutorial proposal must contain complete contact information for the tutorial organizer. Call for Demonstrations Facilities are available at Hong Kong University for demonstrating innovative virtual reality applications and tools. If you are interested in demonstrating the results of your research contact the General Chair at the address below by March 15, 1996. A special demonstration session will be scheduled if enough interest is shown. General Conference Information The conference's technical program will be held at Hong Kong University, and special arrangements will be made at a hotel in Hong Kong's downtown area for attendee accommodation. The hotel location is close to the major tourist sites, cultural centers, and night life, making this is an ideal opportunity for a family vacation. Hong Kong's excellent air connections makes this the ideal starting point for an Asian vacation, or a tour of the major VR research laboratories in this part of the world. Further information on VRST'96 can be obtained from the general chair at the following address: Dr. Mark Green Department of Computing Science University of Alberta Edmonton, Alberta, T6G 2H1, Canada mark@cs.ualberta.ca (403) 492-4584 (403) 492-1071 (FAX) Information can also be obtained from the VRST'96 WEB page at: URL http://web.cs.ualberta.ca/~mark/vrst96.html From rem-conf-request@es.net Thu Feb 22 10:06:37 1996 Received: from dxmint.cern.ch by osi-west.es.net with ESnet SMTP (PP); Thu, 22 Feb 1996 07:06:04 -0800 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA16564; Thu, 22 Feb 1996 16:06:00 +0100 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA16097; Thu, 22 Feb 1996 16:05:55 +0100 Message-Id: <9602221505.AA16097@dxcoms.cern.ch> Subject: MBONE Announcement: ATLAS Plenary meetings at CERN To: rem-conf@es.net Date: Thu, 22 Feb 1996 16:05:55 +0100 (MET) From: Christian Isnard - CERN/CN/CS X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 907 CERN is pleased to announce the MBONE broadcast of the next Plenary Meetings of the ATLAS LHC Experiment Provisional agenda: ------------------ Thursday 7th March, 09:00-13:00 (GMT+1): Physics Working Group 14:00-17:30 (GMT+1): Plenary Meeting (Part I) Friday 8th March, 08:30-13:00 (GMT+1): Plenary Meeting (Part II) The session will be advertised in sd session directory as "CERN ATLAS". vat (audio) and nv (video) will be used with ttl 127. In case of questions or problems about this broadcast please contact . Best regards, -------------------------------------------------------------------- Christian Isnard CERN - CN/CS/EN isnard@dxcoms.cern.ch European Laboratory for Particle Physics Computers and Networks division CH-1211 Geneva 23 - Switzerland From rem-conf-request@es.net Thu Feb 22 10:19:41 1996 Received: from virginia.edu (actually mars.itc.Virginia.EDU) by osi-west.es.net with ESnet SMTP (PP); Thu, 22 Feb 1996 07:19:15 -0800 Received: from archive.cs.virginia.edu by mail.virginia.edu id aa20446; 22 Feb 96 10:13 EST Received: from viper.cs.Virginia.EDU (viper-fo.cs.Virginia.EDU [128.143.136.16]) by archive.cs.Virginia.EDU (8.7.1/8.6.6) with SMTP id KAA02167 for ; Thu, 22 Feb 1996 10:13:41 -0500 (EST) Received: by viper.cs.Virginia.EDU (5.x/SMI-2.0) id AA22499; Thu, 22 Feb 1996 10:13:40 -0500 Date: Thu, 22 Feb 1996 10:13:40 -0500 From: jorg@viper.cs.virginia.edu Message-Id: <9602221513.AA22499@viper.cs.Virginia.EDU> To: rem-conf@es.net Subject: CFP - HPDC Focus Workshop on Multimedia and Collaborative Environments CALL FOR PAPERS HPDC Focus Workshop on MULTIMEDIA AND COLLABORATIVE ENVIRONMENTS ON Center, Syracuse, New York. August 6-9, 1996 This workshop is part of the FIFTH IEEE INTERNATIONAL SYMPOSIUM ON HIGH PERFORMANCE DISTRIBUTED COMPUTING (HPDC-5) to be held on August 6-9, 1996 at the ON Center, Syracuse, New York. ------------------------------------------------------------------------------ IMPORTANT DATES: SUBMISSION DEADLINE FOR EXTENDED ABSTRACTS (5 pages) March 8, 1996 NOTIFICATION OF ACCEPTANCE April 18, 1996 FULL PAPER DUE (10 pages) May 31, 1996 ADDITIONAL INFORMATION: http://www.cs.virginia.edu/~hpdc-focus/ ------------------------------------------------------------------------------ THEME: With the availability of broadband multi-service networks and with recent advances in multimedia technology, the creation of collaborative environments that offer location-independent shared visualization and interaction tools is becoming increasingly feasible. By providing shared virtual spaces for interaction and communication that go beyond desktop videoconferencing, collaborative environments enable the creation of the virtual analog to laboratories, meeting places, and classrooms. The objective of this workshop is to bring together researchers and developers working in multimedia computing and collaborative environments. The workshop is a forum for engineers and scientists to exchange ideas and research results relating to the state-of-the and future directions of wide-area collaborative environments. TOPICS OF INTEREST: Papers and demonstrations are solicited in all areas of distributed multimedia systems and collaborative environments, including, but not limited to: - Broadband Network Transport - Collaboration Tools - Distance Learning Systems - Electronic Communities - Media Servers - Multimedia Networks - Multimedia Models, Frameworks, and Document Architectures - Network-Based Hypermedia - Quality-of-Service - Security - Software for Distributed Multimedia - Synchronization - Tele-Presence Applications - Wireless Multimedia Systems - Video-On-Demand Services - Video-Conferencing Tools - Virtual Environments HPDC GENERAL CHAIR: Geoffrey Fox, NPAC, Syracuse University, (315)443-4741, hpdc@npac.syr.edu WORKSHOP CO-CHAIRS: Kim Mills, NPAC, Syracuse University Jorg Liebeherr, University of Virginia PROGRAM COMMITTEE: Wolfgang Effelsberg, University of Mannheim Edward A. Fox, Virginia Tech Simon Gibbs, GMD Germany Colin Maunder, BT Laboratories Steven McCanne, Lawrence Berkeley Laboratory Roy Rada, Washington State University Ralf Steinmetz, IBM ENC Rick Stevens, Argonne National Laboratory Marc Willebeek-LeMair, IBM Research Raj Yavatkar, Intel Hui Zhang, Carnegie-Mellon University REGISTRATION AND LOCAL ARRANGEMENTS: Peggy Van Arnam, Syracuse University Phone:(315) 443-3333 Fax: (315) 443-1168 e-mail: MJVANARN@SUADMIN.BITNET PAPER SUBMISSIONS: Authors are requested to submit by March 8, 1996, five copies of an extended abstract (not to exceed 5 pages) to: Prof. Jorg Liebeherr Computer Science Department University of Virginia Charlottesville, VA 22903 PHONE: (804) 982-2212 FAX: (804) 982-2214 EMAIL: jorg@cs.virginia.edu Authors are encouraged to submit in postscript format via ftp to ftp://ftp.cs.virginia.edu/pub/hpdc-focus/. Instructions for electronic submissions are available at http://www.cs.virginia.edu/~hpdc-focus/. All submissions must include name and affiliation of the authors, a contact address of the main author, an abstract, and keywords. Accepted papers will appear as part of the HPDC-5 Proceedings. Selected papers will be invited for submission to Special Issues of "Concurrency: Experience and Practice" and the "Computer Communications Journal". Paper Submission Deadline: March 8, 1996 Notification of Acceptance: April 18, 1996 Full Paper due (10 pages): May 31, 1996 DEMONSTRATIONS: Proposals are invited for presentations and live demonstrations of distributed multimedia systems and collaborative environments. Demonstrations will be selected on the basis of technical merit, novel and interesting features, and feasibility. The computing and storage systems to be used for demonstrations during the conference will be connected by a local ATM network and Ethernet. In addition, the conference ATM backbone network will be connected to the NYNET testbed, an ATM Wide Area Network that connects most of main university campuses, industry research labs, and government labs in New York State. Through the ATM connection to the NYNET testbed, it is feasible to access all the High Performance Computing Systems available at the Northeast Parallel Architectures Center (NPAC) at Syracuse University and the Theory Center at Cornell University (e.g., IBM SP2, CM5, Ncube, MasPar, etc.). The organization committee can facilitate obtaining the required resources to run accepted demonstrations. Demonstrations of both in-house and commercial applications, as well as academic and corporate research are sought. Proposals should contain: * A one-page abstract providing the title and description of the demonstration; * Names, affiliations, postal and email addresses, and phone and fax numbers of the demonstrators; * A description of the hardware, software, and technical, on-site requirements or the demonstration. Proposals for demonstrations should be submitted to: Prof. Jorg Liebeherr Computer Science Department University of Virginia Charlottesville, VA 22903 PHONE: (804) 982-2212 FAX: (804) 982-2214 EMAIL: jorg@cs.virginia.edu Submission Deadline for Proposals: March 8, 1996 Notification of Acceptance: April 18, 1996 ------------------------------------------------------------------------- SPONSORS: - IEEE Computer Society - Northeast Parallel Architectures Center (NPAC) at Syracuse University - New York State Center of Advance Technology in Computer Applications and Software Engineering (CASE) Center at Syracuse University IN COOPERATION WITH: - ACM SIGCOMM - Rome Laboratory From rem-conf-request@es.net Thu Feb 22 11:19:45 1996 Received: from nren-vod.arc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Thu, 22 Feb 1996 08:19:21 -0800 Received: by nren-vod.arc.nasa.gov (940816.SGI.8.6.9/1.35) id IAA02929; Thu, 22 Feb 1996 08:19:19 -0800 Date: Thu, 22 Feb 1996 08:19:19 -0800 From: garyp@nren-vod.arc.nasa.gov (Gary Paden) Message-Id: <199602221619.IAA02929@nren-vod.arc.nasa.gov> To: rem-conf@es.net Subject: NASA Shuttle Prelaunch Video For the upcoming NASA Shuttle Mission presentation NASA KSC is providing some interesting prelaunch video. Both NASA Ames and NASA KSC would be interested in getting the user communities feed-back on this prelaunch video. Please provide us some feed-back on whether you feel this is interesting and educational coverage or if you feel the coverage is boring and over-baring. Your comments and suggestions are appreciated. Gary Paden NASA Ames/Sterling garyp@nren-vod.arc.nasa.gov (415)604-0082 From rem-conf-request@es.net Thu Feb 22 15:51:37 1996 Received: from la.cyberworks.net by osi-west.es.net with ESnet SMTP (PP); Thu, 22 Feb 1996 12:50:58 -0800 Received: (from aleph1@localhost) by la.cyberworks.net (8.7.3/8.7.3/cyberworks) id NAA27830; Thu, 22 Feb 1996 13:30:02 -0800 Date: Thu, 22 Feb 1996 13:30:00 -0800 (PST) From: Elias Levy To: rem-conf@es.net Subject: Tunnel? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Anyone out there a few hoops from cyberworks.net willing to provide a tunnel? Our network provider is Net99 and we connected to their Los Angeles POP. Thanks in advance. Elias Levy / technology@cyberworks.net Director of Technology CyberWorks, Inc. http://www.cyberworks.net/ From rem-conf-request@es.net Thu Feb 22 20:10:56 1996 Received: from verdi.Eng.UniPR.IT by osi-west.es.net with ESnet SMTP (PP); Thu, 22 Feb 1996 17:10:25 -0800 Received: by verdi.Eng.UniPR.IT (4.1/1.34) id AA23719; Fri, 23 Feb 96 02:09:19 +0100 Date: Fri, 23 Feb 96 02:09:19 +0100 From: broggi@CE.UniPR.IT (Alberto Broggi) Message-Id: <9602230109.AA23719@verdi.Eng.UniPR.IT> To: rem-conf@es.net Subject: CFP: Hawaii Intl Conf: ENGINEERING COMPLEX COMPUTER SYSTEMS Should you receive multiple copies of this call-for-papers, please accept my apologies. If you maintain a list of call-for-papers, please add this to your list. ============================================================================== CALL FOR PAPERS * ENGINEERING COMPLEX COMPUTER SYSTEMS * Thirtieth Annual HAWAII INTERNATIONAL CONFERENCE ON SYSTEMS SCIENCES HICSS - 30 Maui, Hawaii, January 7-10, 1997 Papers are invited for the Minitrack on ENGINEERING COMPLEX COMPUTER SYSTEMS as part of the Advanced Technology track at the Hawaii International Conference on System Sciences (HICSS). 1. PURPOSES Modern computer systems and applications embody many different characteristics and properties that are currently addressed, studied, and optimized independently. Nevertheless, although it is of basic importance to focus on these aspects independently, as a whole these properties feature a complex interrelationship, and thus a higher-level view of the complete project becomes mandatory. While perhaps some of the earlier computer systems could be described, designed and implemented with a particular focus on one objective (such as fault-tolerance or timeliness), or using a single method (such as Structured Programming), it is very questionable whether such modern and future applications can be. Nowadays almost all electronic products are becoming more and more software based: complex computer systems are becoming common in many sectors, such as manufacturing, communications, defense, transportation, aerospace, hazardous environments, energy, health care, etc. These systems feature a number of different characteristics (such as distributed processing, heterogeneous computational paradigms, high speed networks, novel bus systems, or special-purpose hardware enhancements in general) and performance requirements (such as real-time behavior, fault tolerance, security, adaptability, development time and cost, long life concerns). The concurrent satisfaction of the systems requirements have a considerable impact on the hardware characteristics and vice-versa. The analysis of the complete project, as a whole, is a major point in the design of the computer system itself and plays a basic role throughout the entire system life. The ECCS Minitrack will bring together industrial, academic, and government experts from these various disciplines, to determine how the disciplines' problems and solution techniques interact within the whole system. Researchers, practitioners, tool developers and users, and technology transition experts are all welcome. 2. ADDRESSED TOPICS: Papers are solicited on all major aspects of ECCS including specifying, designing, prototyping, building, testing, operating, maintaining, and evolving of complex computer systems, including: * Software engineering, re-engineering, reverse engineering * Complex real-time architectures, tools, environments and languages * AI and intelligent systems * Database and data management * Dependable real-time systems * Virtual reality, multimedia, real-time imaging * Algorithms, optimization and analysis * Analytical techniques * Megaprogramming, visual programming * Performance estimation, prediction and optimization * Prototyping and testing techniques * Formal methods and formal specification techniques * Hardware/software co-design * Communications, networking, mobile computing * Highly heterogeneous, distributed and parallel platforms * Case studies and project reports 3. MINITRACK COORDINATORS Alberto Broggi Alexander D. Stoyenko Dip. Ingegneria dell'Informazione Real-Time Computing Laboratory, CIS Universita` di Parma New Jersey Institute of Technology I-43100 Parma, Italy Newark, New Jersey 07102 USA Fax: +39 - 521 905723 Fax: (201) 596-5777 Email: broggi@CE.UniPR.IT Email: alex@vulcan.njit.edu Papers should be submitted to: Alberto Broggi HICSS'97 ECCS Coordinator Dipartimento di Ingegneria dell'Informazione Universita` di Parma, Viale delle Scienze I-43100 Parma, Italy 4. FURTHER AND UP-TO-DATE INFORMATION: Further information about the ECCS Minitrack are available at the following WWW address: http://WWW.CE.UniPR.IT/hicss/eccs If you wish to receive automatic updates about this event, please send Email to: broggi@CE.UniPR.IT indicating "ECCS" as subject. * INSTRUCTIONS FOR SUBMITTING PAPERS: 1. Submit 6 (six) copies of the full paper, consisting of 20 - 25 pages double-spaced including title page, abstract, references and diagrams directly to the minitrack coordinator. 2. Do not submit the paper to more than one minitrack. The paper should contain original material and not be previously published or currently submitted for consideration elsewhere. 3. Each paper must have a tile page which includes the title, full name of all authors, and their complete addresses including affiliation(s), telephone number(s) and e-mail address(es). 4. The first page of the paper should include the title and a 300-word abstract. * DEADLINES: March 15, 1996: Abstracts submitted to track coordinators for guidance and indication of appropriate content: authors unfamiliar with HICSS or those who wish additional guidance are encouraged to contact any coordinator to discuss potential papers. June 1, 1996: Full papers submitted to the appropriate track, or minitrack coordinator. August 31, 1996: Notification of accepted papers mailed to authors. October 1, 1996: Accepted manuscripts, camera-ready , sent to minitrack coordinators; one author from each paper must register by this time. November 15, 1996: All other registrations must be received. Registrations received after this deadline may not be accepted due to space limitation. * CONFERENCE PROCEEDINGS: The conference Proceedings are published and distributed by IEEE Computer Society. The ENGINEERING COMPLEX COMPUTER SYSTEMS Minitrack is part of the Advanced Technology. For more information on the Advanced Technology Track contact: Ralph H. Sprague, Jr. E-mail: sprague@hawaii.edu Voice: (808) 956-7082 Fax: (808) 956-9889 * OTHER CONFERENCE TRACKS There are three other majors tracks in the conference: Software, Digital Documents, and Information Systems. The Information Systems Track has several minitracks that focus on a variety of research topics in Collaboration Technology, Decision Support and Knowledge-Based Systems, and Organizational Systems and Technology. For more information on the other tracks, please contact: Software Technology Track: Hesham El-Rewini rewini@unocss.unomaha.edu Digital Documents Track: M. Stuart Lynn msylnn@ucop.edu Information Systems Track: Ralph H. Sprague, Jr. sprague@hawaii.edu Jay F. Nunamaker, Jr. nunamaker@bpa.arizona.edu Eileen Dennis (Track Assistant) edennis@uga.cc.uga.edu The purpose of HICSS is to provide a forum for the interchange of ideas, research results, development activities, and applications among academicians and practitioners in computer-based systems sciences. The conference consists of tutorials, advanced seminars, presentations of accepted papers, open forum, tasks forces, and plenary and distinguished guest lectures. There is a high degree of interaction and discussion among the conference participants because the conference is conducted in a workshop-like setting. For more information on the conference, please contact the conference coordinator: Barbara Edelstein College of Business Administration University of Hawai'i 2404 Maile Way Honolulu, HI 96822 Voice: (808) 956-3251 Fax: (808) 956-9685 E-mail: hicss@hawaii.edu or visit the World Wide Web page: http://www.cba.hawaii.edu/hicss From rem-conf-request@es.net Thu Feb 22 21:18:14 1996 Received: from qucis.queensu.ca by osi-west.es.net with ESnet SMTP (PP); Thu, 22 Feb 1996 18:17:45 -0800 Received: from teaspoon.qucis.queensu.ca by qucis.queensu.ca (5.x/SMI-SVR4-qs1.6) id AA18468; Thu, 22 Feb 1996 21:17:31 -0500 Received: by teaspoon.qucis.queensu.ca (SMI-8.6/SMI-SVR4-qc1.3) id VAA07929; Thu, 22 Feb 1996 21:17:28 -0500 Date: Thu, 22 Feb 1996 21:17:26 -0500 (EST) From: Zhenjun Zhu X-Sender: zhuz@teaspoon To: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Problem: Started sd, but it never sees any session. I simply started sd by doing >sd Is there anything extra that I have to do? Or anything to do with my local computing environment? Any comment or suggestion is appreciated. ************************************************** Zhenjun Zhu Graduate Student Department of Computing and Information Science Queen's University, Kingston, Canada zhuz@qucis.queensu.ca ************************************************** From rem-conf-request@es.net Thu Feb 22 23:10:15 1996 Received: from IETF.cnri.reston.VA.US by osi-west.es.net with ESnet SMTP (PP); Thu, 22 Feb 1996 20:09:41 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa19484; 22 Feb 96 18:59 EST To: rem-conf@es.net Subject: IETF Mailing: LA Multicast Guide Date: Thu, 22 Feb 96 18:59:14 -0500 From: Steve Coya Message-ID: <9602221859.aa19484@IETF.CNRI.Reston.VA.US> Los Angeles IETF Multicast Guide - DRAFT (as of 2/22/96) Following is the tentative schedule of plenary meetings and working group sessions to be transmitted; to interpret the acronyms, see the agenda (available via FTP from ds.internic.net as /ietf/0mtg-agenda.txt). It is possible that this schedule will be modified. MULTICAST GUIDE Note that times are in US Pacific Standard Time (PST). UTC (aka GMT) also provided. MONDAY 0900-0930 0930-1130 1300-1500 1530-1730 1930-2200 (UTC) 1700-1730 1730-1930 2100-2300 2330-0130 0330-0600 ==========+=============+=============+==========+=============+============+ CHAN 1 |intro plenary| radius | poised95| ipngwg | ipsec | ==========+=============+=============+==========+=============+============+ CHAN 2 | " | rsvp | apptsv | rps | mmusic | ==========+=============+=============+==========+=============+============+ TUESDAY 0900-1130 1300-1500 1530-1730 1930-2200 (UTC) 1700-1930 2100-2300 2330-0130 0300-0600 ==========+=============+=============+==========+=============+ CHAN 1 | appaom | avt | poised95 | dhc | ==========+=============+=============+==========+=============+ CHAN 2 | mmusic | rps | ngtrans | intserv | ==========+=============+=============+==========+=============+ WEDNESDAY 0900-1130 1300-1500 1530-1730 1930-2200 (UTC) 1700-1930 2100-2300 2330-0130 0330-0600 ==========+=============+=============+==========+=============+ CHAN 1 | dnssec | cidrd | tspatm | iab | ==========+=============+=============+==========+=============+ CHAN 2 | rsvp | ipngwg | rtfm | idmr | ==========+=============+=============+==========+=============+ THURSDAY 0900-1130 1300-1500 1530-1630 1630-1830 (UTC) 1700-1930 2100-2300 2330-0030 0030-0230 ==========+=============+=============+==============+============+ CHAN 1 | atommib | nbmav6 |tech. plenary |open plenary| ==========+=============+=============+==============+============+ CHAN 2 | tcplw | ttcp-bof | " | " | ==========+=============+=============+==============+============+ There will be no multicasting of sessions on Friday, March 8 1996. Each day's program may also be replayed by tape delay from: 2330 (UTC): 0730 Advice for remote participants: Please keep your microphones muted and your video transmissions disabled during the plenaries and working group sessions, unless or until invited to respond by the chair of the session. Vat users can disable reception of accidental sources of audio multicasts (such as people who forget to mute their mics) by clicking in the box next to that source's name. From rem-conf-request@es.net Fri Feb 23 03:48:43 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 23 Feb 1996 00:48:07 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA17191; Fri, 23 Feb 1996 00:48:06 -0800 Date: Fri, 23 Feb 1996 00:48:06 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: Re: AVT session at Los Angeles IETF? In-Reply-To: <1.5.4b11.16.19960210141741.112fe304@pop.best.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A week or two ago, we discussed here whether or not the Audio/Video Transport working group should meet at the LA IETF. I think there are several topics of interest. It was suggested that some AVT topics might be discussed in the MMUSIC sessions, but it looks like there is a full agenda for those sessions. Allison Mankin has offered the slot previously scheduled for a Transport Area Directorate open meeting. Accordingly: *** There will be an AVT WG session on Tuesday at 1300 to 1500 *** I'm still working on the agenda, but I expect the following will be included: - the draft payload format for H.263 video - payload formats for hierarchical encodings - extending RTP for non A/V applications - coordinating interoperation and standardization As before, additional suggestions would be welcome. -- Steve From rem-conf-request@es.net Fri Feb 23 05:58:11 1996 Received: from ceres.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Fri, 23 Feb 1996 02:57:24 -0800 Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Fri, 23 Feb 1996 11:55:27 +0100 X-Mailer: exmh version 1.6.5 12/11/95 To: rem-conf@es.net cc: ietf@cnri.reston.va.us From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: Infocom'96 tutorials (incl. Multimedia Conferencing) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Feb 1996 11:55:14 +0100 Sender: schulzrinne@fokus.gmd.de Infocom'96 (March 24-28, San Franscisco) advance registration for the conference and the tutorials ends February 23rd. (You save about 20% by registering early.) For further information, see http://www.research.att .com/~hgs/infocom96/ Note that Infocom'96 features a number of interesting tutorials: Half day tutorials: Wireless Communication Networks, by Don Cox, Stanford University Image and Video Compression, by Avideh Zakhor, UC Berkeley Full day tutorials: Optical Networking, by Rajiv Ramaswami, IBM High-Performance Networks: From Ethernet to ATM by Pravin Varaiya, UC Berkeley Broadband Networking: Models and Techniques for Control, Design and Management, by Debasis Mitra, AT&T Bell Laboratories Multimedia Conferencing over the Internet, by Van Jacobson, Lawrence Berkeley Laboratory -- Henning Schulzrinne email: schulzrinne@fokus.gmd.de GMD-Fokus phone: +49 30 25499 182 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin URL: http://www.fokus.gmd.de/step/hgs From rem-conf-request@es.net Fri Feb 23 08:39:31 1996 Received: from relay7.UU.NET by osi-west.es.net with ESnet SMTP (PP); Fri, 23 Feb 1996 05:38:51 -0800 Received: from iisc.ernet.in by relay7.UU.NET with SMTP id QQaedy11030; Fri, 23 Feb 1996 08:38:43 -0500 (EST) Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id AA17755; Fri, 23 Feb 96 19:14:25+0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA04293; Fri, 23 Feb 96 19:07:18+0530 From: anand@ece.iisc.ernet.in (SVR Anand) Message-Id: <9602231337.AA04293@ece.iisc.ernet.in> Subject: Re: AVT session at Los Angeles IETF? To: casner@precept.com (Stephen Casner) Date: Fri, 23 Feb 96 19:07:17 GMT+5:30 Cc: rem-conf@es.net In-Reply-To: ; from "Stephen Casner" at Feb 23, 96 12:48 am X-Mailer: ELM [version 2.3 PL11] Hello Is there a move to define an interface service definition for RTP ? (Shall we say RTPI). I feel that, for interoperability, standardisation of protocol interface is as much important as protocol itself. Sockets, TLI are the inspiration. Please let me know your ideas/opinions on this. Regards Anand. From rem-conf-request@es.net Fri Feb 23 10:48:26 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Fri, 23 Feb 1996 07:44:32 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 23 Feb 1996 15:35:39 +0000 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: anand@ece.iisc.ernet.in (SVR Anand) cc: casner@precept.com (Stephen Casner), rem-conf@es.net Subject: Re: AVT session at Los Angeles IETF? In-reply-to: Your message of "Fri, 23 Feb 1996 19:07:17 GMT." <9602231337.AA04293@ece.iisc.ernet.in> Date: Fri, 23 Feb 1996 15:35:37 +0000 Message-ID: <1844.825089737@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk > Is there a move to define an interface service definition for RTP ? >(Shall we say RTPI). I feel that, for interoperability, standardisation of >protocol interface is as much important as protocol itself. Sockets, TLI are >the inspiration. > > Please let me know your ideas/opinions on this. What do you intend to hide behind the interface? Given that just about every field in an RTP header needs to be specified on a per packet basis by a sending application and certainly needs to be visible by the receiving application, APIs like sockets and TLI seem totally inappropriate to me. ALF is much more appropriate than a layered approach to these sort of protocols, and this usually implies more intelligence moves into the application as it's the only place that can deal appropriately with it. Now an RTP library might be appropriate, but that doesn't really need standardisation within a body like the IETF. Mark From rem-conf-request@es.net Fri Feb 23 13:03:50 1996 Received: from burdell.cc.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 23 Feb 1996 10:03:08 -0800 Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.7.1/8.6.9) with ESMTP id NAA08614; Fri, 23 Feb 1996 13:03:06 -0500 (EST) Received: (from kevin@localhost) by flora.cc.gatech.edu (8.7.1/8.6.9) id NAA18634; Fri, 23 Feb 1996 13:03:05 -0500 (EST) Date: Fri, 23 Feb 1996 13:03:05 -0500 (EST) From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199602231803.NAA18634@flora.cc.gatech.edu> To: rem-conf@es.net Subject: Stored video and vic... Cc: mccanne@ee.lbl.gov Rem-conf and Steve: I'm running vic on a Sun with a SunVideo card and instead of pulling video >from the SunVideo card, I'd like to pull it from a file. I would like to create the source file using the SunVideo card so that should simply the problem of formats, etc. How hard would it be to do this, and are there any plans for such a feature? -Kevin Almeroth From rem-conf-request@es.net Sat Feb 24 02:28:34 1996 Received: from relay7.UU.NET by osi-west.es.net with ESnet SMTP (PP); Fri, 23 Feb 1996 23:28:06 -0800 Received: from iisc.ernet.in by relay7.UU.NET with SMTP id QQaegr04363; Sat, 24 Feb 1996 02:27:42 -0500 (EST) Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id AA05217; Sat, 24 Feb 96 13:03:24+0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA14600; Sat, 24 Feb 96 12:56:17+0530 From: anand@ece.iisc.ernet.in (SVR Anand) Message-Id: <9602240726.AA14600@ece.iisc.ernet.in> Subject: Re: AVT session at Los Angeles IETF? To: vinay@mcast.com (Vinay Kumar) Date: Sat, 24 Feb 96 12:56:17 GMT+5:30 Cc: rem-conf@es.net In-Reply-To: <199602231725.JAA07863@apache.mcast.com>; from "Vinay Kumar" at Feb 23, 96 9:25 am X-Mailer: ELM [version 2.3 PL11] Vinay If my understanding is correct, RTP profile allows for correct encoding and decoding of packets apart from giving guidelines for the implementers. This essentially means a strict protocol spec of RTP itself. When I refer to the interface for RTP, I mean an interface between RTP user and RTP service provider. So far as RTP is concerned RTP being the user of Network service provider, can use Socket interface. As the number of RTP impementations increase, there is a possibility that each of the implementors give their own proprietary interfaces to RTP services. As a result, portability can be a serious issue. This can happen even if these multitude of implementations conform to RTP profiles. In other words I am of the opinion that RTPI should have a rigid interface that may as well look like ABC (param1, param2,...); where ABC gives one of RTP services and param1, and so on are standardized arguments. One argument I can forsee against this proposition is that the flexibility RTP will be compromised. But with many RTP libraries giving fancy mechanisms to access RTP services, interoperability within RTP community itself can become a big issue. Just imagine the plight of an application programmer. If he writes an application using RTP.lib1, then he cannot easily port his application if he finds RTP.lib2 elsewhere. (RTP.lib1 and RTP.lib2 being different implementations of RTP following same profile). I sincerely see a need for RTPI. I can only hope that the RTP community see what I see :-) Regards Anand. > > Did you mean RTP profiles ? The profile should help you define what you call > the interface service definition. Right ? > Regards > --- > Vinay From rem-conf-request@es.net Sat Feb 24 11:52:35 1996 Received: from ceres.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Sat, 24 Feb 1996 08:52:06 -0800 Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Sat, 24 Feb 1996 17:50:33 +0100 X-Mailer: exmh version 1.6.5 12/11/95 To: rem-conf@es.net From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: Vigrapix freezes SPARCs? Mime-Version: 1.0 Content-Type: text/plain Date: Sat, 24 Feb 1996 17:50:30 +0100 Sender: schulzrinne@fokus.gmd.de I'm using a Vigrapix board to provide a web camera (http://www.fokus.gmd.de/step/view/). Unfortunately, the board seems to be causing unexplained system lock-ups every few days. There are no /var/adm log messages, L1-A does not work and only a power-cycle will fix things. I would normally expect some operating system problem, but we upgraded my system to Solaris 2.5, without improvement. I moved the board to a SPARCstation 10 (uniprocessor) from my dual-processor SPARC 20 - and it's showing the same behavior again, even though the machine had been running for weeks without problem before adding the board. Also, my SPARC 20 is now working fine again. Thus, I only have circumstantial evidence that the cause of the problem is the Vigrapix board, but whichever machine has the board seems to be the only among a 100+ SPARCstations we have around here that locks up on a regular basis. I'm using a slightly modified grab_rgb script to grab a frame every two minutes. Has anybody else had similar experiences? Thanks. Henning -- Henning Schulzrinne email: schulzrinne@fokus.gmd.de GMD-Fokus phone: +49 30 25499 182 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin URL: http://www.fokus.gmd.de/step/hgs From rem-conf-request@es.net Sat Feb 24 12:39:26 1996 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Sat, 24 Feb 1996 09:38:58 -0800 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14458(8)>; Sat, 24 Feb 1996 09:38:45 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16136>; Sat, 24 Feb 1996 09:38:35 -0800 To: Henning Schulzrinne cc: rem-conf@es.net Subject: Re: Vigrapix freezes SPARCs? In-reply-to: Your message of "Sat, 24 Feb 96 08:50:30 PST." <96Feb24.092351pst."14631(12)"@alpha.xerox.com> Date: Sat, 24 Feb 1996 09:38:30 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <96Feb24.093835pst.16136@ecco.parc.xerox.com> In message <96Feb24.092351pst."14631(12)"@alpha.xerox.com> you write: > [...] Also, my SPARC 20 is now working fine again. Thus, I only have > circumstantial evidence that the cause of the problem is the Vigrapix > board, but whichever machine has the board seems to be the only among a > 100+ SPARCstations we have around here that locks up on a regular > basis. I'm using a slightly modified grab_rgb script to grab a frame > every two minutes. Has anybody else had similar experiences? > We have dozens of machines here at PARC using VigraPix boards (or their predecessor, which is pretty much identical hardware), and none of them show any problems of this sort. Many are used to transmit video continuously, so they get plenty of exercise. One potential difference is that pretty much all of the machines at PARC with them are still running SunOS 4.1.3 or 4.1.3_U1. I don't have any experience with Vigra's Solaris 2.x driver. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Sat Feb 24 16:28:50 1996 Received: from paradigm.webvision.com by osi-west.es.net with ESnet SMTP (PP); Sat, 24 Feb 1996 13:28:25 -0800 Received: by paradigm.webvision.com (940816.SGI.8.6.9/940406.SGI) id NAA02466; Sat, 24 Feb 1996 13:18:24 -0800 Date: Sat, 24 Feb 1996 13:18:24 -0800 Message-Id: <199602242118.NAA02466@paradigm.webvision.com> From: dave madden To: rem-conf@es.net Subject: subscribe subscribe From rem-conf-request@es.net Mon Feb 26 03:23:00 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 26 Feb 1996 00:22:18 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA19706; Mon, 26 Feb 1996 00:22:01 -0800 Date: Mon, 26 Feb 1996 00:22:01 -0800 (PST) From: Stephen Casner To: SVR Anand Cc: rem-conf@es.net Subject: Re: AVT session at Los Angeles IETF? In-Reply-To: <9602240726.AA14600@ece.iisc.ernet.in> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Anand, > As the number of RTP impementations increase, there is a possibility > that each of the implementors give their own proprietary interfaces to RTP > services. As a result, portability can be a serious issue. That depends. I consider interoperability to be more important than portability. If it turns out most effective to build RTP into each application, then porting RTP is just part of porting that app. I happen to think there is room for library implementations of RTP, and those would have to be ported, too, or have a compatible API as you suggest. But we may not have enough experience to set an API in stone. This would be a reasonable topic for discussion in LA. Is there anyone who would want to make a short presentation? Another topic, suggested by a query from Kevin Almeroth, is RTP (or more specificaly RTCP) monitoring. This is an that apps are just beginning to explore. Anyone have some work on RTP/RTCP monitoring to discuss? -- Steve From rem-conf-request@es.net Mon Feb 26 04:11:59 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Mon, 26 Feb 1996 01:08:05 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 26 Feb 1996 09:06:56 +0000 To: rem-conf@es.net Subject: Call For Papers for IEEE Global Internet 1996 Date: Mon, 26 Feb 1996 09:06:52 +0000 Message-ID: <908.825325612@cs.ucl.ac.uk> From: Jon Crowcroft Apologies to Multiple copy recipients Call For Papers for IEEE Global Internet 1996 London, England, November 20 and 21, 1996 The conference takes place during Globecom'96 and will be held at the Queen Elizabeth II Conference Centre in London. Goals The mini-conference will be jointly organized by the two IEEE Communications Society Technical Committees on Internet and Computer Communications. It will provide an open forum for the communications and computer networking communities to review the state-of-the-art technologies and applications of the evolving Global Internet. It will also provide an opportunity to highlight solutions to pressing issues, establish a vision for the future, and challenge the participants to press forward in their research and engineering efforts to meet business and industry needs for global internetworking. The mini-conference will include keynote speeches, tutorials and panel discussions by leaders in these areas, invited papers by recognized experts, and contributed papers by active researchers in the field. The conference will put special emphasis on hands-on experiences with actual implementations and widespread applications. Panel Discussions Internet Exporting, Trading, Marketing Java The Global Internet -- Technical Progress in Worldwide Internetworking Tutorials Nov. 18, 1996 (Monday) WWW/Java, Management, Security Java (John Daigle) Interactive Multimedia over the Internet (Mark Handley/Ian Wakeman) Nov. 22, 1996 (Friday) Integrated Services Internet Internet Security (Ran Atkinson) IP/ATM (Dave Ginsberg) Call for Papers Topics Submissions should be on key topics including the following: 1. General topics: Evolution of the Internet and WWW: past, present, and future Legal and regulatory issues (e.g., censorship) Privacy, security and billing 2. WWW technology and applications: Protocol evolution and extensions Tools and browsers Authoring environments Retrieval and resource discovery Information representation, modeling and filtering Consistency, integrity and security User and application interfaces Nomadic software Virtual reality Integration of real time data Design techniques for Web applications Kiosk systems Computer based training, teaching and CSCW WWW applications for corporate "intranets" 3. Internetworking technologies and applications Routing, addressing, naming, and large scale multicast ATM, Frame Relay and SMDS as part of the Internet Performance and reliability Nomadic computing and communications Multimedia services to the desktop, e.g., real-time audio/video conferencing, signaling, QoS guarantees Interactive multimedia video, sound and more on commercial networks Internet telephony Distributed simulation Internet management experiences and solutions Enterprise networking architectures and applications Broadband consumer/home access to the Internet Virtual corporate networks Security, billing, and privacy for electronic commerce How to submit papers Electronic submissions are preferred. If your browser supports file upload (Netscape 2.0 does), you can use the form at: http://gaia.cs.umass.edu:80/tccc/internet96/ If you cannot use upload, please email PostScript to either: Jon Crowcroft (jon@cs.ucl.ac.uk) Henning Schulzrinne (schulzrinne@fokus.gmd.de) If you cannot submit your paper in electronic form, mail it to: Professor J. Crowcroft Department of Computer Science UCL Gower Street London WC1E 6BT England Submissions by fax are not accepted. Important Dates 15/may/96 -- Deadline for contributed paper submission 15/jul/96 -- Notification of paper acceptance to authors 1/sep/96 -- Revised manuscript due Conference Committee General Chair Brian Carpenter (Chair IAB, CERN), Technical Chair Jon Crowcroft (UCL) Vice Technical Chair Henning Schulzrinne (IEEE Communications Society Internet Technical Committee) Tatsuya Suda (IEEE Communications Society Technical Committee on Computer Communications) Technical Committee Grenville Armitage Fred Baker Bob Braden Andrew T. Campbell Brian Carpenter CERN-CN Nim K. Cheung Jon Crowcroft Laura Cunningham John N. Daigle Sally Floyd Raj Jain Srinivasan Keshav Jim Kurose Craig Partridge Henning Schulzrinne Jonathan M. Smith Joe Touch John Wroclawski Yechiam Yemini Lixia Zhang From rem-conf-request@es.net Mon Feb 26 10:04:59 1996 Received: from chile.ncren.net by osi-west.es.net with ESnet SMTP (PP); Mon, 26 Feb 1996 07:04:28 -0800 Received: (from tas@localhost) by chile.ncren.net (8.7.3/8.7.3) id KAA16894 for rem-conf@es.net; Mon, 26 Feb 1996 10:04:27 -0500 (EST) Date: Mon, 26 Feb 1996 10:04:27 -0500 (EST) From: Tim Seaver Message-Id: <199602261504.KAA16894@chile.ncren.net> To: rem-conf@es.net Subject: Design and the Information Age Workshop MCNC will be providing an MBONE multicast of the NSF-sponsored workshop on "Design and the Information Age" to be held at MCNC March 1 and 2. The session will be receive-only and will use vat and nv formats at ttl 127. It will be announced with sd as "Design Workshop" and will run from 8:30 am to 3 pm each day. The agenda for the workshop is available online at http://www.ncren.net/Data/DOCs/design-conf.html. Please let me know of any questions or problems with this multicast session. Thanks, Tim Seaver MCNC / NC-REN tas@ncren.net From rem-conf-request@es.net Mon Feb 26 16:08:18 1996 Received: from mercury.Sun.COM by osi-west.es.net with ESnet SMTP (PP); Mon, 26 Feb 1996 13:07:49 -0800 Received: by mercury.Sun.COM (Sun.COM) id NAA22182; Mon, 26 Feb 1996 13:07:47 -0800 Received: from jadeite.eng.sun.com (jadeite-93.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28778; Mon, 26 Feb 1996 13:07:42 -0800 Received: from valathar by jadeite.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA04123; Mon, 26 Feb 1996 13:07:39 -0800 Date: Mon, 26 Feb 1996 13:07:43 -0800 (PST) From: "Michael F. Speer" Reply-To: "Michael F. Speer" Subject: draft-speer-mccanne-avt-layered-video-00.txt To: rem-conf@es.net Cc: speer@Eng.Sun.COM Message-Id: Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: text X-Sun-Content-Length: 294 X-Sun-Charset: ascii Folks: Enclosed is a draft for how to use RTP with layered video sessions that Steve Mccanne of LBNL and I wrote. This is what I had planned dicussing at the upcoming AVT session at the LA IETF. Sorry that I did not get it into Internet-Drafts in time. Thanks, Michael Speer Steve Mccanne ---------- X-Sun-Data-Type: text X-Sun-Content-Length: 7483 X-Sun-Data-Name: draft-speer-mccanne-avt-layered-video-00.txt X-Sun-Data-Description: default X-Sun-Charset: ascii Internet Engineering Task Force Michael F. Speer draft-speer-mccanne-avt-layered-video-00.txt Sun Microsystems, Inc. Steven McCanne LBNL Date: March 1, 1996 Expires: Sept 1, 1996 RTP usage with Layered Multimedia Streams 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Distribution of this document is unlimited. Abstract This draft describes how one should make use of RTP (rfc1889) when employing layered media streams. This document is meant for implementors of internet multimedia applications that want to use RTP and layered media streams. draft-speer-mccanne-avt-layered-video-00.txt [Page 1] INTERNET-DRAFT Layered Multimedia Streams March 1996 1 Introduction This memorandum describes how to use RTP (Real-Time Transport Protocol, rfc1889) with layered multimedia streams. 2 Layered Video Today, most multimedia applications place the responsibility of rate-adaptivity at the source. In multicast transmission, source-adaptation, as discussed in [3], leads to the source not being to meet the conflicting bandwidth requirements of the all receivers. This usually leads to the least-common denominator scenarios, where the smallest pipe in the network mesh dictates the quality and fidelity of the overall live multimedia "broadcast". If the responsibility of rate-adaptation is placed at the receivers, then heterogeneity of such media transmissions is achievable. One approach for moving rate-adaptation from the source to the receivers is to combine a layered source-coder with a layered transmission system. In the context of IP Multicast, Deering proposed a realization of this scheme where a source stripes the progressive layers of a hierarchically represented signal across multiple multicast groups [2]. Receivers can then adapt to network heterogeneity by controlling their reception bandwidth through IP Multicast group membership. In the case of video transmission, several approaches to the layered source-coding problem have been explored, including multirate JPEG [4], subband coding [6], and hierarchical vector quantization [1]. 3 RTP Usage The RTP specification [5] implicitly assumes that the underlying transport/network layer is monolithic. That is, a single RTP session is carried on a single underlying communications layer. However, the layered transmission system described above requires that the stream be partitioned across multiple underlying transport end-points. In RTP, each signal source is identified with a randomly allocated 32-bit source identifier (SRCID) that is unique only within a single session (a collision detection algorithm resolves conflicts). Additionally, each user is identified with a variable-length ``canonical name'' (CNAME) string that is globally unique. Data packets are identified only by SRCID, and periodically, each application broadcasts a binding between it's CNAME and SRCID. Thus, a receiver can collate streams across different sessions (identified by different SRCID's) using the level of indirection provided by the CNAME. Using this framework, we can readily handle layered compression formats by treating each layer as a distinct ``RTP session'' and distributing it on its own multicast group. This is the same approach draft-speer-mccanne-avt-layered-video-00.txt [Page 2] INTERNET-DRAFT Layered Multimedia Streams March 1996 that the RTP uses to relate separate audio and video streams from a single user. However, the ``RTP session per layer'' approach adds unnecessary complexity. Not only does it force each receiver to manage all the CNAME/SRCID bindings, but it requires newly arrived receivers to wait for the binding advertisement before they can start decoding a stream. Another problem is that it creates new error recovery conditions for dealing with conflicting information arriving on the different sessions. We propose to extend RTP semantics. Our proposal is that a single SRCID space is used across all layers and that the core (base) layer be used for SRCID allocation and conflict resolution. With regard to RTCP, we propose that sender identification strings are redundant across all layers and thus should only be transmitted on the base layer. Other than the proposed semantics above, all other RTP rules and practices apply. draft-speer-mccanne-avt-layered-video-00.txt [Page 3] INTERNET-DRAFT Layered Multimedia Streams March 1996 4 References 1. Chaddha, N., Wall, G., and Schmidt, B., "An End to End Software Only Scalable Video Delivery System", Proc. Fifth International Workshop on Network and OS Support for Digital Audio and Video (April, 1995) 2. Deering, S., Internet Multicast Routing: State of the Art and Open Research Issues, MICE Seminar, SICS, Stockholm (Oct 1993). 3. McCanne, S. and Jacobson, V., "Receiver-Driven Layered Multicast". Submitted to SigComm 1996. 4. Hoffman, D. and Speer, M., "Hierarchical Video Distribution over Internet-style Networks". Submitted to the IEEE International Conference on Image Processing (Sept. 1996) 5. Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V., "RTP: A Transport Protocol for Real-Time Applications", rfc1889. 6. Taubman, D. and Zakhor, A. "Multi-rate 3-D Subband Coding of Video". IEEE Transactions on Image Processing 3,5 (Sept 1994) 572-488. 5 Address of the Authors Michael F. Speer Sun Microsystems Computer Corporation 2550 Garcia Ave MailStop UMPK14-305 Mountain View, CA 94043 Voice: +1 415 786 6368 Fax: +1 415 786 6445 E-mail: michael.speer@eng.sun.com Steven McCanne M/S 50B-2239 Lawrence Berkeley National Laboratory One Cyclotron Road Berkeley, CA 94720 Voice: +1 510 486 7520 Fax: +1 510 486 6363 E-mail: mccanne@ee.lbl.gov draft-speer-mccanne-avt-layered-video-00.txt [Page 4] INTERNET-DRAFT Layered Multimedia Streams March 1996 draft-speer-mccanne-avt-layered-video-00.txt [Page 5] From rem-conf-request@es.net Mon Feb 26 16:39:27 1996 Received: from CNRI.Reston.VA.US by osi-west.es.net with ESnet SMTP (PP); Mon, 26 Feb 1996 13:38:43 -0800 Received: from CNRI.Reston.VA.US by CNRI.Reston.VA.US id aa15820; 26 Feb 96 16:37 EST To: rem-conf@es.net From: agenda@CNRI.Reston.VA.US Subject: IETF Mailing: LA Multicast Guide Date: Mon, 26 Feb 96 16:37:16 -0500 Sender: mbeaulie@CNRI.Reston.VA.US Message-ID: <9602261637.aa15820@CNRI.Reston.VA.US> Los Angeles IETF Multicast Guide - DRAFT (as of 2/26/96) Following is the tentative schedule of plenary meetings and working group sessions to be transmitted; to interpret the acronyms, see the agenda (available via FTP from ds.internic.net as /ietf/0mtg-agenda.txt). It is possible that this schedule will be modified. MULTICAST GUIDE Note that times are in US Pacific Standard Time (PST). UTC (aka GMT) also provided. MONDAY 0900-0930 0930-1130 1300-1500 1530-1730 1930-2200 (UTC) 1700-1730 1730-1930 2100-2300 2330-0130 0330-0600 ==========+=============+=============+==========+=============+============+ CHAN 1 |intro plenary| radius | poised95| ipngwg | ipsec | ==========+=============+=============+==========+=============+============+ CHAN 2 | " | rsvp | apptsv | rps | mmusic | ==========+=============+=============+==========+=============+============+ TUESDAY 0900-1130 1300-1500 1530-1730 1930-2200 (UTC) 1700-1930 2100-2300 2330-0130 0300-0600 ==========+=============+=============+==========+=============+ CHAN 1 | appaom | avt | poised95 | dhc | ==========+=============+=============+==========+=============+ CHAN 2 | mmusic | rps | ngtrans | intserv | ==========+=============+=============+==========+=============+ WEDNESDAY 0900-1130 1300-1500 1530-1730 1930-2200 (UTC) 1700-1930 2100-2300 2330-0130 0330-0600 ==========+=============+=============+==========+=============+ CHAN 1 | dnssec | cidrd | tspatm | iab | ==========+=============+=============+==========+=============+ CHAN 2 | rsvp | ipngwg | asid | idmr | ==========+=============+=============+==========+=============+ THURSDAY 0900-1130 1300-1500 1530-1630 1630-1830 (UTC) 1700-1930 2100-2300 2330-0030 0030-0230 ==========+=============+=============+==============+============+ CHAN 1 | atommib | nbmav6 |tech. plenary |open plenary| ==========+=============+=============+==============+============+ CHAN 2 | tcplw | ttcp-bof | " | " | ==========+=============+=============+==============+============+ There will be no multicasting of sessions on Friday, March 8, 1996. Each day's program may also be replayed by tape delay from: 2330 (UTC): 0730 Advice for remote participants: Please keep your microphones muted and your video transmissions disabled during the plenaries and working group sessions, unless or until invited to respond by the chair of the session. Vat users can disable reception of accidental sources of audio multicasts (such as people who forget to mute their mics) by clicking in the box next to that source's name. From rem-conf-request@es.net Mon Feb 26 17:01:49 1996 Received: from hplabs.hpl.hp.com by osi-west.es.net with ESnet SMTP (PP); Mon, 26 Feb 1996 14:01:12 -0800 Received: from opera.hpl.hp.com by hplabs.hpl.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3+HPL1.1SU) id AA101871372; Mon, 26 Feb 1996 13:49:32 -0800 Received: from localhost by opera.hpl.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3+HPL1.1) id AA162561365; Mon, 26 Feb 1996 13:49:25 -0800 Message-Id: <199602262149.AA162561365@opera.hpl.hp.com> To: perform@tay1.dec.com, end2end-interest@isi.edu, ietf@isi.edu, rem-conf@es.net, announcements.chi@xerox.com, arl@arl1.wustl.edu, atm@bbn.com, cip@bbn.com, cnom@maestro.bellcore.com, ccrc@dworkin.wustl.edu, enternet-ec@bbn.com, enternet@bbn.com, f-troup@aurora.cis.upenn.edu, g-troup@dworkin.wustl.edu, globecom@signet.com.sg, hipparch@sophia.inria.fr, icad-request@santafe.edu, iplpdn@cnri.reston.va.us, sigmedia@bellcore.com, smds@cnri.reston.va.us, tcplw@cray.com, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com, xtp-relay@cs.concordia.ca Cc: pitt@hplabs.hpl.hp.com (Daniel Pitt tel. +1 415 857-7096), burak@fokus.gmd.de (Markus Burak) Subject: IEEE LAN/MAN Workshop Date: Mon, 26 Feb 96 13:49:25 -0800 From: Daniel Pitt Please accept our apologies for duplicate messages. We are writing to inform you that the deadline for submissions to the 8th IEEE Workshop on Local and Metropolitan Area Networks is Thursday February 29 (of all days). Your contribution is encouraged. Please note that submissions consist only of one-page text abstracts sent via email, plus slides at the workshop; full papers are not used, and presentations are short and pointed. The goal is to capture the latest ideas and experience, and the experience is intense and rewarding. This year we are most interested in residential networks, mixed-media networks, and real experience, as with ATM. The full call for submissions is attached. We appreciate your considering this workshop and sharing the call with appropriate colleagues. Your immediate action is urged if you wish to secure a place on the program. With kind regards, Daniel Pitt Markus Burak ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CALL FOR SUBMISSIONS EIGHTH IEEE WORKSHOP on LOCAL and METROPOLITAN AREA NETWORKS August 25-28, 1996, Berlin/Potsdam, Germany http://www.fokus.gmd.de/nthp/employees/lanman96/ Local and metropolitan area networks continue to provide a diverse array of technologies, architectures, and protocols in public and enterprise networks. In the near future, these will also be applied to the residential environment. The IEEE Workshop on Local and Metropolitan Area Networks serves as a premier meeting for researchers in these exciting and fast moving areas, and this year for the first time the Workshop will explore the vital new topic of *residential networking*. This workshop provides an informal setting for discussion and interaction across a wide range of related topics. Novel and speculative ideas are strongly encouraged. At the previous Workshop, in March 1995, over twenty countries were represented, making it the most exciting and diverse yet. On this ten-year anniversary of the founding of the Workshop, we will meet in Potsdam, Germany, on the outskirts of Berlin. We hope to see you at this idyllic location on the banks of the river Havel, next to the main square at Potsdam, a centuries-old playground of the rich, powerful, creative, and eccentric. One page *text* abstracts are solicited on the following topics: o Network technologies (metallic, fiber, optical, wireless) o Networks to and within the home o ATM in LANs/MANs and wireless ATM o Station interfacing and design issues o Protocol design for shared media networks o High speed protocol design and performance o Testbeds, experiments, and operational experience o Network applications, service integration, and QoS o Infrastructure networking for wireless communications o Performance modeling This year we would especially encourage submissions dealing with emerging *mixed media networking* (e.g., wireless/wired access, hybrid electronic/photonic networks) and on the application of LAN/MAN technologies to *the residential environment*. Important dates: ----------------- o One-page abstracts must be received by *February 29*, 1996 -- Note the rare date! o Notification of acceptance will be sent by May 15, 1996 Please send the one-page text abstract *by electronic mail* to the Program Co- chairs. ONLY TEXT WILL BE ACCEPTED, NOT POSTSCRIPT. Only abstracts and slides are included in the proceedings, so please do not send or prepare full papers. Include the e-mail addresses and fax numbers of all the authors, and identify the *corresponding author* with whom the program committee will deal. Program Co-Chairs: ------------------ Terry Todd, McMaster University E-mail: todd@mcmaster.ca Martina Zitterbart, Technical University of Braunschweig, Germany E-mail: zit@ibr.cs.tu-bs.de Workshop Co-Chairs: ------------------- Markus Burak, GMD-Fokus, Germany E-mail: burak@fokus.gmd.de Daniel Pitt, Hewlett-Packard Laboratories, USA E-mail: pitt@hpl.hp.com Program Committee: ------------------ Andres Albanese, ICSI Joe Bannister, Aerospace Corp. Abhijit Choudhury, AT&T Bell Labs Luigi Fratta, Politecnico di Milano Mario Gerla, UCLA David Greaves, Cambridge Univ. and ATM Ltd. Paul Kuehn, University of Stuttgart Wolfram Lemppenau, IBM Zurich Research Luciano Lenzini, University of Pisa Nick McKeown, Stanford University Fabio Neri, Politecnico di Torino Yoram Ofek, IBM Watson Research Allyn Romanow, Sun Microsystems David Skellern, Macquarie Univ. Kris Steenhaut, Free Univ. of Brussels Tatsuya Suda, UC Irvine Csaba Szabo, Techical Univ. of Budapest Yutaka Takahashi, Kyoto Univ. Malathi Veeraraghavan, AT&T Bell Labs Chandra Venkatraman, HP Laboratories Sponsored by the IEEE Communications Society, Technical Committee on Computer Communication Check out our dazzling web page at http://www.fokus.gmd.de/nthp/employees/lanman96/ Get a glimpse of Potsdam and an array of photographs, some not even embarrassing, of the last Workshop, held in March 1995 in Florida. From rem-conf-request@es.net Tue Feb 27 00:23:46 1996 Received: from bmrc.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Mon, 26 Feb 1996 21:23:18 -0800 Received: from garfield.CS.Berkeley.EDU (garfield.CS.Berkeley.EDU [128.32.32.118]) by bmrc.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id VAA23856 for <298@bmrc.Berkeley.EDU>; Mon, 26 Feb 1996 21:11:22 -0800 Received: from garfield.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by garfield.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id VAA05608; Mon, 26 Feb 1996 21:11:20 -0800 Message-Id: <199602270511.VAA05608@garfield.CS.Berkeley.EDU> From: Andrew Swan To: 298@bmrc.Berkeley.EDU cc: rowe@cs.berkeley.edu Subject: UC Berkeley Multimedia Seminar 2/21/96 - "A Comparison of Video Shot Boundary Detection Techniques" X-URL: http://www.cs.berkeley.edu/~aswan/ Date: Mon, 26 Feb 1996 21:11:19 -0800 Sender: aswan@bugs-bunny.CS.Berkeley.EDU The sixth Berkeley Multimedia and Graphics seminar of the Spring 1996 semester will be held Wednesday, February 28 from 12:30 - 2:00 PST in 405 Soda Hall. The speaker will be John Boreczky from U.C. Berkeley discussing "A Comparison of Video Shot Boundary Detection Techniques." The talk will be broadcast on the Internet MBONE, beginning at roughly 12:40 PM PST. Please note that you will need vic 2.7 to watch the broadcast. Pre-compiled vic binaries for most architectures are available from: ftp://ftp.ee.lbl.gov/conferencing/vic/alpha-test/ We also hope to broadcast the seminar on the BAGNet -- an sd advertisement should appear by the time the seminar starts. Questions should be directed to Larry Rowe (rowe@cs.berkeley.edu) Abstract: Many algorithms have been proposed for detecting video shot boundaries and classifying shot and shot transition types. Few published studies compare available algorithms, and those that do have looked at a limited range of test material. This talk presents a comparison of several variations of shot boundary detection and classification algorithms including histograms, discrete cosine transform, motion vector, and block matching methods. The performance and ease of selecting good thresholds for these algorithms are evaluated based on a collection of video sequences with a good mix of transition types. Threshold selection requires a tradeoff between recall and precision that must be guided by the target application. An algorithm that combines the shot detection techniques with analysis of the audio track is discussed. This combined algorithm will be used to extract higher level structural and content information from video sequences such as scene and sequence boundaries. -- Andrew Swan aswan@cs.berkeley.edu Plateau Multimedia Research Group http://www.cs.berkeley.edu/~aswan/ From rem-conf-request@es.net Tue Feb 27 03:38:11 1996 Received: from tecfirew.tecsiel.it by osi-west.es.net with ESnet SMTP (PP); Tue, 27 Feb 1996 00:37:35 -0800 Received: (from uucp@localhost) by tecfirew.tecsiel.it (8.6.12/8.6.10) id JAA09097 for ; Tue, 27 Feb 1996 09:37:28 +0100 From: Braito_Norbert@tecpi.tecsiel.it Received: from tecserv.tecsiel.it(193.43.104.81) by tecfirew.tecsiel.it via smap (V1.3) id sma009095; Tue Feb 27 09:37:25 1996 Received: from tecpi (tecpi [193.43.104.9]) by tecserv.tecsiel.it. (8.6.12/) with ESMTP id JAA16588 for ; Tue, 27 Feb 1996 09:37:31 +0100 Received: from by tecpi with SMTP (1.37.109.16/16.2) id AA259720176; Tue, 27 Feb 1996 09:36:16 +0100 X-Openmail-Hops: 1 Date: Tue, 27 Feb 96 09:35:36 +0100 Message-Id: Subject: How to subscribe Mime-Version: 1.0 To: rem-conf@es.net Content-Type: text/plain; charset=US-ASCII; name="00m9s9e" Content-Transfer-Encoding: 7bit Please, tell me how to subscribe to this mailing list ____________________________________________________________________________ __ _/_/ /_/_/ Norbert Braito phone: +39 (50) 512-511 (operator) /_/_/ Finsiel S.p.A. +39 (50) 512-636 (direct) /_/_/ Via S.Maria, 19 fax: +39 (50) 589-015 /_/_/ 56126 Pisa - Italy +39 (50) 904-620 ====== email: braito@tecsiel.it ____________________________________________________________________________ From rem-conf-request@es.net Tue Feb 27 05:34:47 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Tue, 27 Feb 1996 02:34:09 -0800 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id CAA01733 for ; Tue, 27 Feb 1996 02:33:37 -0800 Message-Id: <199602271033.CAA01733@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: rem-conf@es.net Subject: new low cost high performance video capture board Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Feb 1996 02:33:36 -0800 From: "Amancio Hasty Jr." Hi, In FreeBSD Land we have been very happy with the matrox meteor PCI video capture board. We use it for all sort of things, nv, vic, watching tv (thats pci-to-pci) pumping 36MB/sec thru the system 8) The only problem with the meteor is its relative high cost $500 and availability. OmniMedia has developed a meteor clone which works with the standard matrox meteor driver in FreeBSD: ----- Talisman Sequence P1S $299 PCI Video Capture Card based on Phillips 7110/7116/7196 chipset Contact Information: OmniMedia Technology, Inc. 455 DeGuigne Drive Sunnyvale, CA USA 94086 +1 408 774 9999 (voice) +1 408 337 9919 (fax) rrvr@omt.com (email) ----- Enjoy, Amancio From rem-conf-request@es.net Tue Feb 27 12:16:34 1996 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Tue, 27 Feb 1996 09:16:04 -0800 Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.6.12/8.6.12) with SMTP id JAA06150 for ; Tue, 27 Feb 1996 09:16:02 -0800 Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.29.1 #4) id m0trT0L-000HzTC; Tue, 27 Feb 96 09:16 PST Original-Received: by ccm.hf.intel.com (ccmgate 3.2 #6) Tue, 27 Feb 96 09:16:01 PST PP-warning: Illegal Received field on preceding line Date: Tue, 27 Feb 96 09:11:00 PST From: Christian Maciocco Message-ID: To: rem-conf@es.net Subject: Re: draft-speer-mccanne-avt-layered-video-00.txt >We propose to extend RTP semantics. Our proposal is that a single >SRCID space is used across all layers and that the core (base) layer >be used for SRCID allocation and conflict resolution. With regard to >RTCP, we propose that sender identification strings are redundant >across all layers and thus should only be transmitted on the base >layer. >Other than the proposed semantics above, all other RTP rules and >practices apply. By using a single SRCID space for all layers and having RTCP aggregate the layers report, I think that we lose important per-layer feedback information. Christian Maciocco christian_maciocco@ccm.jf.intel.com From rem-conf-request@es.net Tue Feb 27 12:24:30 1996 Received: from nren-vod.arc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 27 Feb 1996 09:24:05 -0800 Received: by nren-vod.arc.nasa.gov (940816.SGI.8.6.9/1.35) id JAA00515; Tue, 27 Feb 1996 09:24:03 -0800 Date: Tue, 27 Feb 1996 09:24:03 -0800 From: garyp@nren-vod.arc.nasa.gov (Gary Paden) Message-Id: <199602271724.JAA00515@nren-vod.arc.nasa.gov> To: rem-conf@es.net Subject: NASA Shuttle Broadcast At approximately 8:00a.m. PST the NASA Ames mbone broadcast machine experienced a system failure, as a result the STS-75 Shuttle broadcast was down for a short time. As a backup NASA KSC has taken over the duration of the broadcast. Future Shuttle broadcast will continue to be originated from NASA Ames. For the STS-75 broadcast please open the NASA -KSC STS-75(audio) and (video) sessions from sd. NASA Ames apologizes for any inconvenience this may have caused you. Gary Paden NASA Ames/Sterling paden@pioneer.arc.nasa.gov (415)604-0082 From rem-conf-request@es.net Tue Feb 27 13:21:16 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 27 Feb 1996 10:20:40 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 27 Feb 1996 18:20:15 +0000 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: rem-conf@es.net Subject: sorting out legacy payload types and protocols Date: Tue, 27 Feb 1996 18:20:11 +0000 Message-ID: <7207.825445211@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk I'm trying to decide how much legacy support to put into sdr/sdr-gateway for old formats now SDPv2 makes it no longer legal to have text payload types with RTP protocol streams. The recent changes to SDP haven't really made the problem worse - just made it more obvious there is a problem. Basically there is a big problem with almost all mbone tools when anyone announces them with sd because there is insufficient information in SDPv1 descriptions to unambiguously decide what to do. Currently the sd->sdr gateway assumes the following: - all audio is vat-3 audio - all video is RTP video Basically there's nothing sensible I can do about audio - people will either have to give up using sd I think if you want to use RTP audio reasonably elegantly, or use an attribute as a flag (which will only add to the confusion as some people won't parse it and some will). For video it's a real mess. I didn't want to add RTPv1 as a specific protocol in SDPv2 because this would seem to prolong the use of obsolete legacy protocols. Current nv and IVS still use RTPv1, though I expect an RTPv2 version of IVS will be released before too long. - if I get a session description with "format" vic, I can assume it's RTPv2 without difficult problem, but have no information as to its real format. I think assuming h261 probably won't hurt, but I'm not certain of this. - even assuming H.261, there's the old/new H.261 vic 2.6/vic 2.7 incompatibility, but I see increasing numbers of vic 2.7 sessions, so perhaps I can just ignore vic 2.6? - if I get a session description with "format" ivs, I can assume it's RTPv1 and the obsolete H.261 format without difficult problem, but don't want to have to support this. - if I get a session description with format nv, I have no idea if it's RTPv1 (nv 3.3b) or RTPv2 (vic). Whatever I assume, I get it wrong for some people. There is much less ambiguity if you announce a session from sdr, with the exception of nv. I could add an RTPv1 protocol type to disambiguate, but I'm much more tempted to assume that it's RTPv2 and anyone still running nv 3.3beta will just find they can't see anyone using vic. Is this what it takes to get rid of these extremely out of date versions of code out there? How much will it hurt anyone if I don't provide any support for the obsolete protocols in nv 3.3beta or ivs 3.x? Will this increase or decrease the confusion? Will it prolong the use of obsolete protocols? Mark From rem-conf-request@es.net Tue Feb 27 13:46:17 1996 Received: from lpsmail.ksc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 27 Feb 1996 10:45:39 -0800 Received: from tenet.ksc.nasa.gov (smtpgw [163.206.51.100]) by lpsmail.ksc.nasa.gov (8.6.12/8.6.12) with SMTP id NAA04294 for ; Tue, 27 Feb 1996 13:45:33 -0500 Received: by tenet.ksc.nasa.gov with Microsoft Mail id <31337B4D@tenet.ksc.nasa.gov>; Tue, 27 Feb 96 13:44:45 PST From: "Kyramarios, Steve N" To: Rem-Conf Cc: "Reed, Marie B" , "Brown, Charles T" Subject: STS-75 Broadcast Update Date: Tue, 27 Feb 96 13:10:00 PST Message-ID: <31337B4D@tenet.ksc.nasa.gov> Encoding: 8 TEXT X-Mailer: Microsoft Mail V3.0 Due to a hardware failure at NASA-Ames Research Center, NASA-KSC is broadcasting both audio and video of STS-75. The new names that will appear in sd are "NASA-KSC STS-75 Audio" and "NASA-KSC STS-75 Video". Sorry for any inconvenience that this may have caused. -Steve Kyramarios/NASA-KSC From rem-conf-request@es.net Tue Feb 27 15:11:59 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Tue, 27 Feb 1996 12:11:21 -0800 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id MAA00911; Tue, 27 Feb 1996 12:10:34 -0800 Message-Id: <199602272010.MAA00911@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: "Kyramarios, Steve N" cc: Rem-Conf , "Reed, Marie B" , "Brown, Charles T" Subject: Re: STS-75 Broadcast Update In-reply-to: Your message of "Tue, 27 Feb 1996 13:10:00 PST." <31337B4D@tenet.ksc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Feb 1996 12:10:33 -0800 From: "Amancio Hasty Jr." Is it possible to broadcast audio using gsm format instead of pcm? Also, I am curious what the parameters that you are using for the video trasmission? Tnks, Amancio >>> "Kyramarios, Steve N" said: > Due to a hardware failure at NASA-Ames Research Center, NASA-KSC is > broadcasting both audio and video of STS-75. The new names that will appear > in sd are "NASA-KSC STS-75 Audio" and "NASA-KSC STS-75 Video". > > Sorry for any inconvenience that this may have caused. > > > -Steve Kyramarios/NASA-KSC From rem-conf-request@es.net Tue Feb 27 15:13:29 1996 Received: from alink-gw.apple.com by osi-west.es.net with ESnet SMTP (PP); Tue, 27 Feb 1996 12:11:47 -0800 Received: from A17_206_40_181.apple.com by alink-gw.apple.com with SMTP (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA17021; Tue, 27 Feb 96 12:08:56 -0800 for rem-conf@es.net Received: from [17.255.9.125] by kanadajin.apple.com.eda (4.1/SMI-4.1) id AA23684; Tue, 27 Feb 96 12:06:48 PST X-Sender: singer@taurus.apple.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Feb 1996 12:08:53 -0800 To: rem-conf@es.net From: mbonetv@apple.com (Dave Singer) Subject: Mbone tools for the Macintosh Coinciding with the current shuttle mission and our coverage of the Grammy Awards, we are making available Macintosh MBone reception tools, currently in alpha, to the rem-conf community. The MBone tools can receive the VAT, RTPv1 and RTPv2 protocols, with the mu-law, GSM, NV, and H.261 codecs supported. There is currently no whiteboard support. Some of these codecs require Power Macintoshes. IP multicast is supported only in Open Transport, the networking software which has been shipping on 7500, 8500 and 9500 machines, and which is now available more generally at ftp://ftp.support.apple.com/pub/apple_sw_updates/US/mac/Unsupported/ The MBone tools themselves are being released as part of the QuickTime Live! coverage of the Grammy Awards, (see http://grammy.apple.com/), and can be found at ftp://ftp.grammy.apple.com/pub/qttv/MBoneTVMac.sea.hqx Feedback on these tools can be sent to mbonetv@apple.com. Feedback on the QuickTime TV coverage of the Grammy Awards can be sent to grammytv@apple.com. We hope you enjoy using these tools, and look forward to your comments. Mark Maxham and Dave Singer, for the QuickTime TV team From rem-conf-request@es.net Tue Feb 27 15:37:15 1996 Received: from milou.comp.lancs.ac.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 27 Feb 1996 12:36:10 -0800 Received: from tina.comp.lancs.ac.uk by milou.comp.lancs.ac.uk; Tue, 27 Feb 1996 20:34:06 GMT From: Randa Message-Id: <13037.199602272035@tina.comp.lancs.ac.uk> Received: by tina.comp.lancs.ac.uk; Tue, 27 Feb 1996 20:35:49 GMT Subject: RTP Source code To: rem-conf@es.net Date: Tue, 27 Feb 1996 20:35:49 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I am starting a simple new project for transferring video over RTP. I do not know which MBONE application that is suitable for my video project to look at RTP source code in it. From rem-conf-request@es.net Tue Feb 27 16:26:28 1996 Received: from mercury.thepoint.net by osi-west.es.net with ESnet SMTP (PP); Tue, 27 Feb 1996 13:24:31 -0800 Received: from smtpgate.finall.com by mercury.thepoint.net (8.6.12/) id QAA16983; Tue, 27 Feb 1996 16:37:28 -0500 Received: by smtpgate.finall.com with Microsoft Mail id <31339FD2@smtpgate.finall.com>; Tue, 27 Feb 96 16:20:34 PST From: "Jung, Michael" To: "'rem-conf@es.net'" Subject: HELP Date: Tue, 27 Feb 96 16:24:00 PST Message-ID: <31339FD2@smtpgate.finall.com> Encoding: 2 TEXT X-Mailer: Microsoft Mail V3.0 HELP From rem-conf-request@es.net Tue Feb 27 20:09:33 1996 Received: from bh.kyungpook.ac.kr by osi-west.es.net with ESnet SMTP (PP); Tue, 27 Feb 1996 17:08:57 -0800 Received: from palgong.kyungpook.ac.kr (palgong.kyungpook.ac.kr [155.230.12.2]) by bh.kyungpook.ac.kr (8.6.12H1/8.6.9) with ESMTP id KAA06861 for ; Wed, 28 Feb 1996 10:07:31 +0900 Received: by palgong.kyungpook.ac.kr (8.6.12H1/8.6.9) id KAA06481; Wed, 28 Feb 1996 10:09:47 +0900 Date: Wed, 28 Feb 1996 10:09:47 +0900 From: hsj@palgong.kyungpook.ac.kr (Sang-Jin Her) Message-Id: <199602280109.KAA06481@palgong.kyungpook.ac.kr> To: rem-conf@es.net Subject: RT300 Video compression Content-Length: 388 Hi! folks. I have tested videoconferencing using VB RT300. And I have used Video for Window 1.1e. but the compression time of 160x120 image is about 180 ms. I request RT300 chip labrary for fast compression, but in Korea , this library is not supported. Please, tell me RT300 library( Development tool kit ). or Creative Lab E-mail address for technical supports. Thanks in advance. From rem-conf-request@es.net Wed Feb 28 14:33:44 1996 Received: from VNET.IBM.COM by osi-west.es.net with ESnet SMTP (PP); Wed, 28 Feb 1996 11:33:04 -0800 Received: from RALVM6.VNET.IBM.COM by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5765; Wed, 28 Feb 96 14:33:01 EST Date: Wed, 28 Feb 96 14:33:01 EST From: ellesson@VNET.IBM.COM To: rem-conf@es.net, casner@precept.com, petrack@VNET.IBM.COM Subject: Framework for Compressed RTP FROM: ED ELLESSON, RALVM6(ELLESSON) / ellesson@vnet.ibm.com Networking Systems Architecture, C70/B664 P.O. 12195, Research Triangle Park, NC 27709 Subject: Framework for Compressed RTP Scott and I will be at the avt meeting in LA, and have asked Steve Casner for some time on the avt agenda to discuss the following draft. Comments/suggestions would be most appreciated! (Sorry for the lateness of the draft, so close to the meeting time next week.) ************************************************************************* Internet Draft (Preliminary) Scott Petrack IBM Ed Ellesson IBM February 1996 Framework for C/RTP: Compressed RTP Using Adaptive Differential Header Compression Abstract: RTP (Realtime Transport Protocol) has been adopted as a Proposed Standard and is being widely implemented for the synchronized transmission of time-stamped data over IP networks, and has been shown to be effective at LAN speeds, T1 speeds, and Basic Rate ISDN speeds (128 kbps). However, a large number of users access the Internet at speeds of 14.4 and 28.8 kbps. In order for such users to realize the maximum benefit of realtime audio and video applications, it is reasonable to apply whatever means possible to reduce header overhead. A framework for header compression of RTP and for associated control protocols is herein proposed for use in these low bandwidth realtime scenarios. Introduction: RTP (Realtime Transport Protocol) has been adopted as a Proposed Standard, and is being widely implemented, for the synchronized transmission of time-stamped data over IP networks, and has been shown to be effective at LAN speeds, T1 speeds, and Basic Rate ISDN speeds (128 kbps). However, a large number of users access the Internet at speeds of 14.4 kbps and 28.8 kbps. In order for such users to realize the maximum benefit of realtime applications, it is reasonable to apply whatever means possible to reduce header overhead. By reducing header overhead, the relative amount of bandwidth available for transmission of realtime audio or video packets can be dramatically increased, while maintaining acceptable packetization delay. At these low speeds, a few kbps in additional realtime packet throughput can make a dramatic difference in user perception of quality in the received audio or video. This draft introduces the concepts which we have utilized to reduce header overhead in realtime applications. In order to negotiate or pre-arrange header compression options, a session control protocol is assumed. The Session Description Protocol (SDP), defined by the mmusic working group, could easily be modified to pre-arrange such compression options for loosely controlled conference sessions. For tightly controlled sessions, the Simple Conference Invitation Protocol (SCIP) also being defined by the mmusic working group, could be used to negotiate or re-negotiate such options. Alternatively, a modified H.245 protocol could also be used to negotiate header compression options as part of the "capabilities exchange". The specific modifications to these protocols to control header compression options are beyond the scope of this draft. RTP's overhead is approximately 12 bytes per packet, at minimum. The impact of this RTP overhead, when used over low speed access lines, is aggravated by the fact that in typical real-time audio applications, the packet size is particularly small. A telephony application using an advanced codec might transmit 24 bytes every 30msecs. Each packet is a separate UDP write, which adds an additional 8 bytes. Thus the total overhead for both RTP and UDP is approximately 20 bytes for each 24 byte packet. Over a 14.4 kbps connection, one has no choice but to group packets together to reduce the bandwidth requirement, which increases delay to an unacceptable degree for realtime interactive voice conversations. Even over a 28.8 kbps link, the overhead of RTP/UDP cuts into the bandwidth available to audio and video applications. This translates directly into larger delays in the available service, because the payloads must be grouped into larger packets to amortize the RTP/UDP overhead. This draft documents two ideas that we have used to reduce the overhead of RTP from 12 bytes to 2 bytes. This reduction allows us to to effectively eliminate the delay caused by RTP overhead on a low speed link. Although applying Van Jacobsen compression to the headers is helpful, it is limited by the rapidly varying sequence number and timestamp information. The general compression scheme described here can be summarized thus: the timestamp and sequence number fields taken together include redundant time signal information. They can be compressed by standard adaptive differential methods. The extra compression is based on two ideas: 1. Use the time-related nature of the sequence and time stamp fields. In many cases, timestamps can be replaced by "timeclick numbers" which are one byte long, and these can be combined with the RTP sequence numbers. In general the timestamps and sequence numbers themselves form a simple time signal, and can be compressed without loss by standard adaptive differential methods. 2. Negotiate compression options before starting the RTP session. In many cases, certain RTP header fields do not change at all during the life of an RTP session. The two ideas presented here can be used independently. For example, one could send all the header fields in each packet, but still use the special time-related nature of some of the fields to compress them. The application that first interested us is transmitting audio and audio/video over a PPP link. In this case the two ideas together give a much more efficient use of bandwidth. Time-related compression: The basic idea here is that one cannot compress time-related data by the usual VJ compression, because time related data is constantly changing. But the changes in the time related data are often simple to model, and an "adaptive differential" scheme can give good lossless compression. For example, suppose there are no packet losses and the time stamp of each packet increases by exactly one. In this case, each timestamp is different, so VJ compression will not compress, but in fact one can dispense entirely with the timestamp field after the first. In general, there are two separate fields which relate to time: the RTP sequence number, and the timestamp. In our internet telephone example, we have an application which sends one UDP packet every 20msecs, except that during silence it sends nothing. We always send the packets in order. Instead of the timestamp and the RTP sequence number, we send a single "timeclick number" with each packet. Each number represents 20 msecs, and from the timeclick number we know exactly when it was sent (modulo 256*20msecs=5.12secs). Thus we have a precise model for timestamps(i.e. timestamps always increase by 20msecs), and this allows us to transmit the information in a single byte. Session control and compression: The second idea is an extension of well known VJ compression. We have found that in multimedia applications over low-speed links, every bit can be very precious. VJ compression is an in-band technique, and uses a few bits to signal a header which doesn't change. One can save several a few hundred bits per second by signalling the static parts of the headers out of band. We now discuss this technique. RTP is designed to run over connectionless, unreliable protocols, but it has inherent in it the idea of an RTP session. We have found that it is very natural to set up, control, and tear down an RTP session using a separate session control protocol, which, in our implementation, uses a reliable form of transmission. The RTP bytestream itself still runs over the unreliable protocol - only the non-real-time control is done via a the session control protocol. One of the important benefits of doing this is that we can compress the unreliable RTP bitstream even further. Example: Think of a simple audio/video transmission application (multicast or unicast). Before streaming begins, some negotiation or advertisement takes place (coder type, block size, bandwidth, etc.). In this way, each side has a common understanding of the coming RTP bytestream. (In our current implementation, the receiver sends a "ready to receive" to the sender, and then the sender can start streaming - an RTP session has begun.) The RTP bytestream itself is sent over UDP/IP to facilitate real time transmission. To change a parameter in a session, the RTP session stops streaming, and only then some new negotiation takes place or the session is torn down and a new one established. One can use this model to implement every commonly used "phone service", including multiparty conferencing. The simplifying assumption is that an RTP parameter can be negotiated only while the RTP stream is not streaming. This negotiation can take place in a comparatively leisurely non-real-time manner. >From an end user perspective, pausing the realtime flow to renegotiate the control state is not unfamiliar. Note that this model is very similar to that provided by an ordinary analog phone call. You pick up the receiver and do some reliable signalling to set up a connection. Once connected, the real-time stream is highly unreliable (noise, echo, etc.). In order to change the control state of the connection, the exchange of real-time data must be suspended or stopped (call must be put "on hold" or disconnected). In analog phone systems, the "on hold" indication is often signalled via a timed "hook flash", or temporary disconnect. In this paused state the real-time bitstream can be renegotiated (e.g., you can dial someone else, etc.). We do not propose this model for all RTP realtime flows, but only those that are associated with applications which can dramatically benefit from header compression signaling via a separate session control mechanism. Here is the precise definition of our session mechanism: 1. The originator contacts the receiver via some negotiation or advertisement protocol and informs or negotiates in non-real-time the bytestream characteristics. (In our implementation, this phase ends with the sender sending a messaging expressing readiness to receive.) 2. At this point the sender can start sending to the receiver using RTP. 3. At any point in the stream, the sender can stop sending and then send a "pause announcement". This pause announcement is sent via the session control protocol. (In our current implementation, the receiver acknowledges this pause announcement.) Similarly, the receiver can send a "pause request" and then wait for the sender to stop sending. (In our current implementation, the sender complies with such a request by stopping to send, and also acknowledges the request by sending a "pause announcement" in the control protocol.) 4. Once the realtime stream is paused, and the correct pause message has been received on each side, then the control connection can be used to renegotiate the bitstream (return to item 1, above), or to end the session. There are two important points about using the above scheme: - The RTP bytestream itself is sent by UDP/IP, a stateless protocol. All the state information is negotiated in the session control protocol. This is possible because there is a very simple synchronization between the two channels, done in non-real time. The statelessness of the RTP stream makes it very simple to fulfill the realtime requirements. - The fact that all negotiation is done BEFORE the RTP stream begins, allows the two sides to agree not to send RTP header information that is going to remain static throughout the session. Without this prior negotiation, some bits would have to be used to flag these RTP header fields. By simply not transmitting these bits at all, one can squeeze several hundred extra bits per second out of a low speed serial link. This is often very precious when one is transmitting realtime audio or video over a 14.4 kbps link. To summarize, although RTP allows the possibility to perform control of the bitstream on the fly, in practice one can often agree in advance not to do this, with no real loss in the useability of the available service, depending on the application. Multicast Considerations: The above discussion spoke about point-to-point unicast only for simplicity. It is easy to generalize to multicast environments, if a advertisement or agreement protocol is used to synchronize the state of the multiple endpoints. The essential ideas (using a session protocol to negotiate the stateless RTP stream, negotiating to omit uneccessary fields, and performing an adaptive differential compression on the time stamps and sequence numbers) apply equally in the multicast case. Summary: We have found that much useful real-time conferencing can be done over 14.4 and 28.8 kbps links. But the difference between the 8+12 byte overhead of RTP/UDP and 8+2 byte overhead of C/RTP can be the difference between acceptable audio/video quality and intolerable audio/video quality. We definitely think that it is worth supporting 14.4kbps links for real-time multimedia. References: 1. H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC1889, 2. H. Schulzrinne, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, 3. M. Handley, V. Jacobson, "SDP: Session Description Protocol", Internet-Draft, Nov. 22, 1995. 4. H. Schulzrinne, "Simple Conference Invitation Protocol", Internet- Draft, February 22, 1996. Author's Addresses: Scott Petrack IBM Science and Technology Center Haifa, Israel Email: petrack@haifasc3.vnet.ibm.com Ed Ellesson IBM Networking Architecture Research Triangle Park, NC, USA Email: ellesson@vnet.ibm.com Regards, Ed Ellesson Emerging Technologies, Networking Architecture T-444-4115, 919-254-4115 / FAX Number: T-444-5410, 919-254-5410 From rem-conf-request@es.net Wed Feb 28 20:19:51 1996 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Wed, 28 Feb 1996 17:19:07 -0800 Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.6.12/8.6.12) with SMTP id RAA07503; Wed, 28 Feb 1996 17:19:04 -0800 Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.29.1 #4) id m0trx1L-000I3LC; Wed, 28 Feb 96 17:19 PST Original-Received: by ccm.jf.intel.com (ccmgate 3.2 #5) Wed, 28 Feb 96 17:19:03 PST PP-warning: Illegal Received field on preceding line Date: Wed, 28 Feb 96 17:16:00 PST From: Jim Toga Message-ID: To: Chunrong_Zhu@ccm.jf.intel.com, internet-drafts@cnri.reston.va.us, rem-conf@es.net Subject: RTP - H.263 Payload Chad. Text item: Colleagues, Attached, please find the revised draft on H.263 payload format for RTP. Comments are welcome and should be directed to the author at czhu@ibeam.intel.com best regards, Jim Toga ************************************************************************* *** voice: 503.264.8816(w) 503.264.3485(fax) *** *** email: jim_toga@ccm.jf.intel.com , jtoga@ishark.intel.com *** *** Intel - Hillsboro, OR. *** ************************************************************************* Text item: rtp263.txt 2/28/96 5:11P Internet Draft RTP Payload for H.263 February 26, 1996 Internet Engineering Task Force Audio-Video Transport WG INTERNET-DRAFT Chunrong "Chad" Zhu Intel Corp. February 26, 1996 Expires: 8/26/96 RTP Payload Format for H.263 Video Stream Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of 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 maybe updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "lid-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 Cost). Distribution of this document is unlimited. Abstract This document specifies the RTP payload format for encapsulating H.263 bitstreams in Real-Time Transport Protocol (RTP). The H.263 payload header is designed for flexibility and simplicity. RTP can use one of three possible modes for H.263 video streams depending on the desired performance characteristics. The shortest header mode (Mode A) results in simplicity and easy recovery of lost packets, brought about by fragmentation at Group of Block (GOB) boundaries. The long header modes (Mode B and C) result in more efficient use of bandwidth, brought about by fragmentation at Macroblock (MB) boundaries. Zhu [Page 1] Internet Draft RTP Payload for H.263 February 26, 1996 1. Introduction This document describes a scheme to packetize an H.263 video stream for transport using RTP [1]. H.263 video stream is defined by ITU-T Recommendation H.263 (referred to as H.263 in this document) [4] for video coding at very low bit rate. RTP is defined by the Internet Engineering Task Force (IETF) to provide end-to-end network transport functions suitable for applications transmitting real-time data over multicast or unicast network services. The complete specification of RTP for a particular application will require a profile specification document [3], a payload format specification, and an RTP protocol document [1]. This document is intended to serve as the payload format specification for H.263 video streams. 2. Definitions For the purpose of this document, the following definitions apply: CIF: Common Intermediate Format. For H.263, a CIF picture has 352 x 288 pixels for luminance, and 176 x 144 pixels for chrominance. QCIF: Quarter CIF source format with 176 x 144 pixels for luminance and 88 x 72 pixels for chrominance. sub-QCIF: picture source format with 128 x 96 pixels for luminance and 64 x 48 pixels for chrominance. 4CIF: picture source format with 704 x 576 pixels for luminance and 352 x 288 pixels for chrominance. 16CIF: picture source format with 1408 x 1152 pixels for luminance and 704 x 288 pixels for chominance. GOB: for H.263, a Group of Blocks (GOB) comprises of k*16 lines, depending on the picture format (k=1 for QCIF, CIF and sub-QCIF, k=2 for 4CIF and k=3 for 16CIF). MB: a macroblock (MB) relates to four blocks of luminance and the spatially corresponding two blocks of chrominance. Each block consists of 8x8 pixels. 3. Design Issues for Packetizing H.263 Bitstream H.263 is based on ITU-T Recommendation H.261 [2] (referred to as H.261 in this document). Although it employs similar techniques to reduce both temporal and spatial redundancy, there are several major differences between the two algorithms that impact the design of packetization schemes significantly. This section summarizes those differences. Zhu [Page 2] Internet Draft RTP Payload for H.263 February 26, 1996 3.1 Optional Features of H.263 In addition to the basic source coding algorithms, H.263 supports four negotiable features to improve performance: Advanced Prediction, PB frames, Syntax-based Arithmetic Coding, and Unrestricted Motion Vectors. They can be used in any combination. These optional features make session management a little harder to handle. Advanced Prediction(AP): four motion vectors instead of one can be used for some macroblocks in the frame. This feature makes recovery from packet loss harder, because more redundant information has to be preserved at the beginning of the packet when fragmenting at macroblock boundaries. PB frames: two frames ( P frame and B frame) are coded into one bitstream with macroblocks from two frames interleaved. From packetization point of view, a MB from the P frame and a MB from the B frame must be treated together because each MB for the B frame are coded based on the corresponding MB for the P frame. Means must be provided to ensure proper rendering of two frames in the right order. Also if part of this combined bitstream is lost, it will impact the two frames, and possibly more. Syntax-based Arithmetic Coding (SAC): Huffman codes are not the only choice for variable length coding. When SAC option is on, the run value pair resulted after quantization of Discrete Cosine Transform (DCT) coefficients will be coded differently from Huffman codes, but macroblock hierarchy will be preserved. Unrestricted motion vector feature does not impact packetization directly. No special treatment is needed. 3.2 GOB Numbering In H.263, each picture is divided into groups of blocks (GOB). GOBs are numbered by vertical scan of the GOBs, starting with the upper GOB and ending with the lower GOB. In contrast, a GOB in H.261 is composed of three rows of 16x16 MB for all QCIF, and three half rows of MB for CIF format. Like H.261, a GOB is divided into macroblocks. The definition of a macroblock is the same as in H.261. Each GOB in H.263 can have a fixed GOB header, but unlike H.261 the use of the header is optional. If the GOB header is present, it may or may not start on a byte boundary. Byte alignment can be achieved by proper bit stuffing by the encoder, but it is not required. Zhu [Page 3] Internet Draft RTP Payload for H.263 February 26, 1996 In summary, a GOB in H.263 is defined and coded with finer granularity with the same source format, thus resulting in more flexibility for packetization than H.261. 3.3 Motion Vectors Encoding Differential coding is used to code motion vectors as variable length codes. Unlike in H.261, where each motion vector is predicted from the previous MB in the GOB, H.263 employs a more flexible prediction scheme, where three candidate predictors are used instead of one. It is done differently depending on the presence of GOB header. If the GOB header is included for a GOB, motion vectors are coded with reference to MBs in this GOB only. But if GOB header is not present for the current GOB, three motion vectors must be available to decode one macroblock, where two of them are from the previous GOB. To decode the whole inter-coded GOB, all the motion vectors must be available from the previous GOB. This can be a major problem for a packetization scheme like the one defined for H.261 when packetizing at MB boundary. Assume a packet starts with one MB but the GOB header is not coded. If the previous packet is lost, then all the motion vectors to predict the motion vector for the MBs in this GOB are not available. In order to decode the received MBs correctly, all the motion vectors for the previous GOB would have to be saved at the beginning of the packet. This would be very expensive in terms of bandwidth. We address these problems by recommending the use of the GOB header for every GOB. In addition, treating the GOB boundary as the picture boundary during the encoding will further improve the visual quality in the presence of packet loss. Several simulations during ITU meetings on H.324 Mobile have also demonstrated its effectiveness and desirability. The encoding strategy of each implementation of H.263 codec is beyond the scope of this document, even though it has very significant impact on visual quality in the presence of packet loss. 3.4 Macroblock Address As specified by H.261, macroblock address (MBA) is encoded with a variable length code to indicate the position of a macroblock within a group of blocks in the H.261 bitstream. H.263 does not code the MBA explicitly, but the macroblock address within a GOB is necessary to recover the decoder state in the presence of packet loss. We propose to include this information in the H.263 payload header for two of the modes (Mode B and Mode C) that allow packetization at MB boundaries. 4. Usage of RTP When transmitting H.263 video streams over the internet, we will directly packetize the output of the encoder. All the bits resulting from the bitstream including the fixed length codes and variable length codes (Huffman codes, or SAC if SAC is used) will be included in the packet. Also we do not intend to multiplex audio and video signals in the same packets, as UDP and RTP provide a much more efficient way to achieve multiplexing. Zhu [Page 4] Internet Draft RTP Payload for H.263 February 26, 1996 RTP does not guarantee a reliable and orderly data delivery service, so a packet might get lost in the network. To achieve a best-effort recovery from packet loss, the decoder needs assistance to proceed with decoding of other packets that are received. Thus it is desirable to be able to process each packet independent of other packets. Like H.261 RTP payload format, we propose to include some frame level information in each packet, such as source format and flags for optional features to assist the decoder in operating efficiently. The H.263 video stream will be carried as payload data within the RTP packets. A new H.263 payload header is defined in section 7, H.263 payload header. This section defines the usage of RTP fixed header and H.263 video packet structure. 4.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 stream: 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. 0 otherwise. Payload Type (PT): The Payload Type shall specify H.263 video payload format. Timestamp: The RTP Timestamp encodes the sampling instance of the first video frame contained in the RTP data packet. The RTP timestamp may be the same on successive packets if a video frame occupies more than one packet. For H.263 video stream, the RTP timestamp is based on a 90 kHz clock, the same as that of RTP payload for H.261 stream. 4.2 Video Packet Structure H.263 compressed bitstream is carried as payload within each RTP packet. For each RTP packet, the RTP header is followed by the H.263 payload header, which is followed by the standard H.263 compressed bitstream. The size H.263 payload header is variable depending on modes used as detailed in the next section. The layout of the RTP H.263 video packet is shown as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.263 Payload Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.263 stream | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhu [Page 5] Internet Draft RTP Payload for H.263 February 26, 1996 5. H.263 Payload Header One H.263 payload header is present for each H.263 video packet as carried within one RTP packet. Three formats (Mode A, Mode B and Mode C) are defined for RTP H.263 payload. In Mode A, a H.263 payload header of four bytes is present before actual compressed H.263 video bitstream in the packet. It allows fragmentation at GOB boundaries. In Mode B, a eight byte H.263 payload header is used and each packet starts at MB boundaries with PB frame option off. Finally, Mode C with a 12 bytes header is provided to support fragmentation at MB boundaries for frames that are coded with PB frame option on. The mode is indicated by the F field and P field in the first two bits of the header. The three modes can be intermixed for one compressed frame. All the modes should be supported by the client application or its drivers. In this section, the H.263 payload format is shown as rows of 32-bit double word. Within each double word, the high order byte shall be transmitted before the low order byte and bits within a byte shall be transmitted in decreasing order, most significant bit first. 5.1 Mode A In this mode, H.263 bitstream will be packetized at GOB boundaries. In other words, each packet will start at the beginning of a GOB, and it can carry one or more MBs or GOBs. Only four bytes are used for the header. Mode A can be used with or without PB frame option. For those GOBs that are smaller than network packet size, this mode is recommended. The H.263 payload header definition for Mode A is shown as follows with F=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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT |EBIT | SRC | R |I|A|S|DBQ| TRB | TR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F: 1 bit The flag bit indicates the format of the header. F=0, Mode A, F=1, Mode B or Mode C. P: 1 bit Optional PB-frame mode as defined by the H.263 [4]. "0" implies normal I or P picture, "1" PB-frame. When F=1, P also indicates modes. Mode B if P=0, Mode C if P=1. SBIT: 3 bits Start bit position specifies number of bits that should be ignored in the first data byte. EBIT: 3 bits End bit position indicates number of bits that should be ignored in the last data byte. Zhu [Page 6] Internet Draft RTP Payload for H.263 February 26, 1996 SRC : 3 bits Source format specifies the resolution of the frames contained as defined by the H.263 [4]. R: 5 bits Reserved, must be 0. I: 1 bit. Set to 1 if current picture is intra-coded. Otherwise 0. Notice this is opposite to the picture coding type in PTYPE as defined within the H.263 bitstream [4]. A: 1 bit Optional Advanced Prediction mode as defined by H.263 [4]. "0" implies off, "1", implies on. S: 1 bit Optional Syntax-based Arithmetic Code mode as defined by the H.263 [4]. 0" off, "1" on. DBQ: 2 bits Differential quantization parameter to calculate quantizer for the B frame based on quantizer for the P frame, when PB frame option is on. The value should be the same as DBQUANT defined by the H.263 [4]. Set to 0 if PB frame option is off. TRB: 3 bits Temporal Reference for the B frame as defined by the H.263 [4]. Set to zero if PB frame option is off. TR: 8 bits Temporal Reference for the P frame as defined by the H.263 [4]. Set to zero if PB frame option is off. 5.2 Mode B In this mode, the H.263 stream can be fragmented at MB boundaries. Thus necessary information is needed at the start of the packet to recover the decoder internal state in the presence of packet loss. It is intended for those GOBs whose sizes are larger than the maximum packet size allowed in the underlining protocol (such as IP). This mode can only be used with PB frame option off. Mode C as defined in the next section can be used to fragment at MB boundaries with PB frame option on. The H.263 payload header definition for Mode B is shown as follows with F=1 and P=0: Zhu [Page 7] Internet Draft RTP Payload for H.263 February 26, 1996 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT |EBIT | SRC | QUANT |I|A|S| GOBN | MBA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMV1 | VMV1 | HMV2 | VMV2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following fields are defined the same as in Mode A: F, P, SBIT, EBIT, SRC, I, A, S. The new fields are defined as follows: QUANT: 5 bits Quantization value for the first MB coded at the starting of the packet. Set to 0 if the packet begins with a GOB header. This is the equivalent of GQUANT defined by the H.263 [4]. GOBN: 5 bits GOB number in effect at the start of the packet. GOB number is specified differently for different resolutions. See H.263 [4] for details. MBA: 8 bits The absolute address of the first MB within its GOB. Unlike in H.261, MB address is not coded explicitly in the bitstream. Instead, MB position is decided relative to its immediate previous MB. In order to continue decoding in the presence of loss of the previous packet, the absolute address of the first MB within its GOB in the packet is coded in the header. HMV1, VMV1, 8 bits each. Horizontal and vertical motion vector predictors for the first MB coded in this packet from the MB on the left. The same as MV1 defined by H.263 [4]. We strongly recommend using GOB header for every GOB. HMV2, VMV2, 8 bits each. Horizontal and vertical motion vector predictors from the block or MB on the left of block number 3 in the current MB when advanced prediction option is on. it is the same as MV1 defined for block number 3 in H.263 [4]. This is needed because block number 3 in the first MB needs the motion vector predictor >from the block to its left, as block number 1. These two fields are not used when advanced prediction is off and must be set to 0 See the H.263 [4] for block organization in a frame. 5.3 Mode C In this mode, H.263 stream can be fragmented at MB boundaries of P frames when the PB frame option is on. It is intended for those GOBs whose sizes are larger than the maximum packet size allowed in the underlining protocol (such as IP). H.263 payload header definition for Mode C is shown as follows with F=1 and P=1: Zhu [Page 8] Internet Draft RTP Payload for H.263 February 26, 1996 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT |EBIT | SRC | QUANT |I|A|S| GOBN | MBA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMV1 | VMV1 | HMV2 | VMV2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TR |DBQ| TRB | R | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following fields are defined the same as in Mode A: F, P, SBIT, EBIT, SRC, I, A, S, TR, DBQ, TRB, and the rest of the fields are defined the same as in Mode B, except field R of 19 bits is reserved and must be set to zero. 5.4 Selection of Modes for H.263 Payload Header Mode A, B and C can be intermixed. The modes shall be selected carefully based on performance characteristics, H.263 coding modes and underlying network protocols. The major advantage of Mode A over Mode B and C is its simplicity. The header is one half and one third of the size of Mode B and C respectively. Transmission overhead is reduced and the savings may be very significant when working with very low bit rates, especially when low latency is desired. Another advantage of Mode A is that it simplifies error recovery in the presence of packet loss. The internal state of the decoder can be recovered at GOB boundaries instead of having to deal with MBs as in Mode B and C, this is because the GOB header and the picture start code are easy to identify. This mode is recommended for GOBs whose size is smaller than the network packet size. The major disadvantage of Mode A is lack of flexibility in packetization and that it does not work when a GOB is larger than the network packet size. Mode B has the advantage of flexibility with fragmentation at MB boundaries with PB frame option off. This mode is necessary when a GOB is larger than the network packet size. It has the disadvantage of higher overhead with a long header of 8 bytes. For small packets, this may not be desirable. Mode C is the same as B, except it allows fragmentation with PB option on at the price of 4 additional bytes. On the other hand, we would like to emphasize that recovery from packet loss will depend on the decoder's ability to use the information provided in the H.263 payload header within the RTP packets. 6. References [1] Henning Schulzrinne, Stephen Casner, Ron Frederick, Van Jacobson, RTP : A Transport Protocol for Real-Time Applications, RFC 1889, 1996. Zhu [Page 9] Internet Draft RTP Payload for H.263 February 26, 1996 [2] Video Codec for Audiovisual Services at px64 kbits/s, ITU-T Recommendation H.261, 1993 [3] RTP Profile for Audio and Video Conference with Minimal Control, 1995. [4] Video Coding for Low Bitrate Communication, ITU-T Recommendation H.263 (draft) , 1995 [5] T. Turletti, C. Huitema, RTP Payload Format for H.261 Video Stream. 1995. 7. Author's Address Chunrong "Chad" Zhu Mail Stop: JF2-78 Intel Architecture Lab Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA Tel: (503) 264-8849 Fax: (503) 264-6067 Email: czhu@ibeam.intel.com 8. Table of Contents 1. Introduction.........................................2 2. Definitions..........................................2 3. Design Issues for Packetizating H.263 Bitstream......2 3.1 Optional Features of H.263...........................3 3.2 GOB Numbering........................................3 3.3 Motion Vectors Encoding..............................4 3.4 Macroblock Address...................................4 4. USAGE OF RTP.........................................4 4.1 RTP Header usage.....................................5 4.2 Video Packet Structure...............................5 5. H.263 Payload Header.................................5 5.1 Mode A...............................................6 5.2 Mode B...............................................7 5.3 Mode C...............................................8 5.4 Selection of Modes for H.263 Payload Header..........8 6. References...........................................9 7. Author's Address....................................10 Zhu [Page 10] From rem-conf-request@es.net Wed Feb 28 20:42:17 1996 Received: from burdell.cc.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 28 Feb 1996 17:41:16 -0800 Received: from dementia.cc.gatech.edu (kevin@dementia.cc.gatech.edu [130.207.8.22]) by burdell.cc.gatech.edu (8.7.1/8.6.9) with ESMTP id UAA08438 for ; Wed, 28 Feb 1996 20:41:07 -0500 (EST) Received: (from kevin@localhost) by dementia.cc.gatech.edu (8.7.1/8.6.9) id UAA04312 for rem-conf@es.net; Wed, 28 Feb 1996 20:41:05 -0500 (EST) Date: Wed, 28 Feb 1996 20:41:05 -0500 (EST) From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199602290141.UAA04312@dementia.cc.gatech.edu> To: rem-conf@es.net Subject: Broadcast from Georgia Tech (Leslie Valiant) On Thursday, February 29th, Georgia Tech will be broadcast a talk by Leslie Valiant of Harvard University. The abstract is included at the end of this message. The talk starts at 4:30pm EST (21:30 GMT) and should run for an hour plus questions. Video is provided using vic; audio is done with vat. Of implementation interest is the fact that this is the first broadcast of an event using our wiring-to-the-classroom. "nomad3" is a Sparc 2 runing Solaris 2.5 and mrouted 3.8. -Kevin Almeroth (kevin@cc.gatech.edu) ------------------------------------------------------------------------- College of Computing Distinguished Lecture featuring Dr. Leslie Valiant, Harvard University "Cognitive Computation" Abstract It has been a long standing goal to explain how the most basic cognitive phenomena, such as memorization, are or might be implemented in the brain. We suggest that the impediments that have been met in pursuing this goal have two major computational sources. First, when conceptualizing any complex system in other computational domains, it has been found necessary to work with models at several different levels. Hence developing models for each one of the appropriate levels between cognitive behavior at one end, and neurons at the other, is a necessary first step. In this talk we will therefore review models at four intermediate levels that we have found useful. The four concern, respectively, a model of common sense rational behavior, a more minimalist level of basic memory and learning tasks ("random access tasks"), an idealized model of neuronal computation ("neuroids"), and, lastly, a neuronal model with more realistic synaptic strength assumptions. We suggest that the second impediment to finding plausible solutions to our problem is that the computational capabilities of neural systems are highly constrained, and are stretched to the limits when performing cognitive tasks. We argue, however, that this constraint can be used to good advantage in our pursuit, since any computational mechanism that does not satisfy the severe quantitative constraints on time, connectivity, or numbers of neurons can be ruled out. From rem-conf-request@es.net Thu Feb 29 07:54:13 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Thu, 29 Feb 1996 04:53:13 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 29 Feb 1996 12:52:33 +0000 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: rem-conf@es.net Subject: alpha version of UCL Mbone Text Editor (nt) available Date: Thu, 29 Feb 1996 12:52:32 +0000 Message-ID: <3714.825598352@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk This is to announce that an alpha release of the UCL Mbone based shared text editor is now available from ftp://cs.ucl.ac.uk/mice/nt/ Binaries are available for SunOS4, SunOS5, Irix and HPUX. More platforms will hopefully be supported in due course. I am very interested in comments, suggestions and feedback, but please note: - it is an alpha release - there are sure to be bugs! - the functionality is minimal right now - some features that should be there aren't. - note also that in general, shared tools are not intended to replace single user tools for normal tasks, but rather to suppliment them, so don't expect loads of bells and whistles to ever be added. - nt should scale up well to large groups, but we've only tested it with up to 20 people in a conference. - I'm away for all of March, so don't expect much in the way of replies from me! Many many thanks to all the MICE and MERCI project partners who tolerated very buggy versions for the last 6 months of Mbone meetings, and in particular to Angela Sasse and Peter Kirstein who didn't object to it taking a year longer that I rashly predicted :-) Mark >From the online help: Nt is a shared text editor designed for use on the Mbone. It is not a word processor (it is not clear that word processing is a useful task to share) and it is not a whiteboard - if you want a whiteboard, wb >from LBL is a much better whiteboard. Using Nt can be very interactive - unless you lock a block of text, anyone else in your session can edit that text or delete it. This is intentional. Many people can (if they wish) edit the same document simultaneously. Many people can even edit the same block of text simultaneously, but if more than one person tries to edit the same line at one time, a conflict will occur, which results in only one of the changes being preserved. In general, it is up to you how you use Nt . You must develop human protocols to be able to collaborate, even in face-to-face meetings, and Nt is no exception. It will work well if you cooperate, and not if you don't. It only provides mimimal protection against disruptive participants Nt tries hard to ensure you don't get confused by unexpected events caused by other users - it always tells you who did what if it can. However, it can't do the impossible, and sometimes network conditions may mean that a change arrives somewhat delayed. If this happens, Nt will reach a consistent result, but this may not be what you expected. Thus we recommend using Nt as part of a multimedia conference in which it is a support tool, rather than as the only channel of communication. From rem-conf-request@es.net Thu Feb 29 09:10:51 1996 Received: from sun2.bnl.gov by osi-west.es.net with ESnet SMTP (PP); Thu, 29 Feb 1996 06:10:24 -0800 Received: from sun2.bnl.gov by sun2.bnl.gov (SMI-8.6/SMI-SVR4) id JAA26822; Thu, 29 Feb 1996 09:10:21 -0500 Sender: lamlap@sun2.bnl.gov Message-ID: <3135B3CD.500@sun2.bnl.gov> Date: Thu, 29 Feb 1996 09:10:21 -0500 From: Lap Chung Lam Organization: Brookhaven National Laboratory Of Department of Energy of USA X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.5 sun4m) MIME-Version: 1.0 To: rem-conf@es.net CC: lam38@leo.cs.newpaltz.edu Subject: Multicast applications for HP-UX 9.05. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have a HP 725 machine runing HP-UX 9.05. I would like to know where I can find the multicast applications for Hp-UX 9.05. I could not find the kernel supporting multicast for HP-UX 9.05. Therefore, I installed the multicast kernel supporting HP-UX 9.01 for my HP-UX 9.05 operating system. But when I ran sd, it gave me following message: IP-ADD_MEMBERSHIP: Can't assign requested address. I want to know what causes this problem, and how I can fix it. Do I have to install the multicast kernel for HP-UX 9.05? If so, where can I get it? Thanks. -- Cheers, Lap Chung. ********************************************************************* Brookhaven National Laboratory Internet: lamlap@sun2.bnl.gov Lap Chung Lam Telephone: (516)344-3210 Computing and Communications WWW: http://www.ccd.bnl.gov/ Building 515, Upton, NY 11973 WWW: http://www.bnl.gov/ ********************************************************************* From rem-conf-request@es.net Thu Feb 29 15:07:26 1996 Received: from CNRI.Reston.VA.US by osi-west.es.net with ESnet SMTP (PP); Thu, 29 Feb 1996 12:06:59 -0800 Received: from mac-53.cnri.reston.va.us by CNRI.Reston.VA.US id aa11853; 29 Feb 96 15:02 EST X-Sender: mbeaulie@newcnri.cnri.reston.va.us Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Feb 1996 15:03:05 -0500 To: rem-conf@es.net From: Marcia Beaulieu Subject: Multicast Change for 35th IETF There has been a change in the Multicast agenda. Thursday, March 7 0900-1130 session, Channel 1 Mobileip will be in that session instead of Atommib. From rem-conf-request@es.net Thu Feb 29 20:42:33 1996 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Thu, 29 Feb 1996 17:42:06 -0800 Received: from ibeam.intel.com (ibeam.jf.intel.com [134.134.208.3]) by ormail.intel.com (8.6.12/8.6.12) with SMTP id RAA13057; Thu, 29 Feb 1996 17:42:03 -0800 Received: from raj by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0tsJvU-000RTSC; Thu, 29 Feb 96 17:46 PST Message-Id: Date: Thu, 29 Feb 96 17:46 PST X-Sender: yavatkar@ibeam.intel.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mccanne@ee.lbl.gov, Christian Maciocco , rem-conf@es.net From: Raj Yavatkar Subject: Re: draft-speer-mccanne-avt-layered-video-00.txt Steve and Mike, I agree with Christian. Other qn I have is, are you assuming that multiple layers will not be sent using different destination group address? At 09:11 AM 2/27/96 PST, Christian Maciocco wrote: > >We propose to extend RTP semantics. Our proposal is that a single > >SRCID space is used across all layers and that the core (base) layer > >be used for SRCID allocation and conflict resolution. With regard to > >RTCP, we propose that sender identification strings are redundant > >across all layers and thus should only be transmitted on the base > >layer. > > >Other than the proposed semantics above, all other RTP rules and > >practices apply. > > By using a single SRCID space for all layers and having RTCP aggregate > the layers report, I think that we lose important per-layer feedback > information. > > Christian Maciocco > christian_maciocco@ccm.jf.intel.com > > >