From rem-conf Sun Jun 01 13:45:46 1997 From rem-conf-request@tmpmail.es.net Sun Jun 01 13:45:46 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wYHJg-0001wr-00; Sun, 1 Jun 1997 13:33:28 -0700 Message-Id: <199706012033.NAA06628@rx7.ee.lbl.gov> To: Peter Parnes cc: "H.A. Kippenhan Jr." , rem-conf@es.net, kippenhan@hep.net Subject: Re: 640x480 support in VIC when using nv encoding In-reply-to: Your message of Sat, 31 May 97 22:05:18 N. Date: Sun, 01 Jun 97 13:33:43 PDT From: Van Jacobson X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list > Which parameter does one need to tweak to get that working under > Solaris2.5.1? I get the following error-message with 'large' and > nv: > > RTVC_CMD_SEND_MESSAGE: Not enough space Peter, I very carefully said "640x480". Full size PAL is 768x576 and the rtvc board doesn't have enough on-board memory to capture an image this size. This is a limitation of the capture board, not vic. To be precise, it's a limit of the braindead XIL "3 band" capture format built into the RTVC firmware. XIL wants a Y U & V for each pixel (3 bytes/pixel) rather than the 4:2:2 format (2 bytes/pixel) the video is actually captured in. This means a full frame image is 768*576*3 = 1327104 bytes & there's only 1210176 bytes of free buffer space on the board. There's another set of microcode for the rtvc that will grab 4:2:2 and this would handle a full size PAL image (884736 bytes) but we were never able to get it working reliably (there were funny chroma artifacts at 8 or 16 pixel boundaries) so vic doesn't use it. - Van From rem-conf Sun Jun 01 23:38:10 1997 From rem-conf-request@tmpmail.es.net Sun Jun 01 23:38:10 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wYQYZ-0003lh-00; Sun, 1 Jun 1997 23:25:27 -0700 From: Toerless Eckert Message-Id: <199706020624.IAA03434@faui40.informatik.uni-erlangen.de> Subject: Re: 640x480 support in VIC when using nv encoding To: van@ee.lbl.gov (Van Jacobson) Date: Mon, 2 Jun 1997 08:24:54 +0200 (MET DST) Cc: peppar@cdt.luth.se, kipp@hep.net, rem-conf@es.net, kippenhan@hep.net In-Reply-To: <199706012033.NAA06628@rx7.ee.lbl.gov> from "Van Jacobson" at Jun 1, 97 01:33:43 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 X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list > set of microcode for the rtvc that will grab 4:2:2 and this would > handle a full size PAL image (884736 bytes) but we were never > able to get it working reliably (there were funny chroma artifacts > at 8 or 16 pixel boundaries) so vic doesn't use it. How about running SunVideo with the XIL framegrabber ? Will that utilize the 4:2:2 ucode ? From rem-conf Mon Jun 02 08:17:12 1997 From rem-conf-request@tmpmail.es.net Mon Jun 02 08:17:12 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wYYfs-0005RK-00; Mon, 2 Jun 1997 08:05:32 -0700 X-SMTP-Posting-Origin: maelstrom.CC.McGill.CA (maelstrom.CC.McGill.CA [132.206.35.2]) Message-ID: <01BC6F44.E3853B30@maelstrom.CC.McGill.CA> From: Computing Centre To: "'mbone@isi.edu'" Cc: "'rem-conf@es.net'" Subject: IEEE ICC'97 broadcast Date: Mon, 2 Jun 1997 11:05:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Hello, I am proud (aren't we always?) to announce the broadcast of selected technical sessions from IEEE's ICC 97 conference, which will happen in Montreal from June 8th to June 12th. ICC 97 is the International Conference on Communications which is sponsered by IEEE. For more info about this conference, you can go to http://happy.comsoc.org/confs/ICC/97/ The broadcast will last 3 days, from June 9 to June 11, inclusive. Rebroadcasts will take place at night to accomodate our friends on the other side of the planet. In the following schedule, a SAS session is a Systems, Applications and Services session. Thanks, Yves Lepage June 9 08:00 - 09:15 Opening Plenary Speakers: Kevin Lynch, Deputy Minister of Industry John McLennan, CEO Bell Canada 09:30 - 10:45 SAS Session 01 Whiter Switching? Dr. Ron Horn 11:15 - 12:30 SAS - Session 06 Challenges Facing the Building of Information Infrastructures Salah Aidarous 14:30 - 17:15 TECHNICAL SESSION - Network Video Services Alex Gelman ------------------------------------------------------------------------- June 10 08:00 - 09:15 SAS Session 10 The Evolution of Broadband Satellite Services Peter Garland 09:15 - 10:30 SAS Session 09 Broadband Wireless Access Richard J. Nowak 10:45 - 13:00 Theme Pleanry Session - Towards the Knowledge Millennium Panelists:Ian Craig, President Nortel Broadband Networks John MacDonald, CTO Bell Canada Bob Lucky, Bellcore Narayana Murthy, Infosys Mario Vecci, Excalibur_TimeWarner Moderator:Tom Rowbotham, British Telecom Director of Technology 14:00 - 17:00 High Speed Access Over Wired Media Vijay Bhagavath -------------------------------------------------------------------------- June 11 09:00 - 12:00 SAS Session 03 Video over IP Gary Crane 14:00 - 15:15 SAS session Content: The Killer Application Victoria Dickenson 15:45 - 17:00 SAS session 02 IP over ATM Rolando Oliver From rem-conf Mon Jun 02 14:43:16 1997 From rem-conf-request@tmpmail.es.net Mon Jun 02 14:43:16 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wYeeq-0000BZ-00; Mon, 2 Jun 1997 14:28:52 -0700 Sender: jcoulter@on.bell.ca Message-ID: <33933AF7.7FF3@on.bell.ca> Date: Mon, 02 Jun 1997 17:28:23 -0400 From: John Coulter Organization: Bell Global Network Operations X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5 sun4m) MIME-Version: 1.0 To: mbone@cilea.it CC: rem-conf@es.net Subject: mistaken mbone reservation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list I made a mistake with my first attempt at booking an mbone session. could you please remove the session on June 25 from 14:00 to 23:00. -- Regards John Coulter Network Engineer Bell Canada Communications Solutions Ph: +1 613 781-8891 FAX:+1 613 781-8891 jcoulter@on.bell.ca From rem-conf Tue Jun 03 07:40:31 1997 From rem-conf-request@tmpmail.es.net Tue Jun 03 07:40:31 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wYuXr-0002yl-00; Tue, 3 Jun 1997 07:26:43 -0700 From: Toerless Eckert Message-Id: <199706031426.QAA19634@faui40.informatik.uni-erlangen.de> Subject: URL's for conferences To: rem-conf@es.net Date: Tue, 3 Jun 1997 16:26:34 +0200 (MET DST) 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 X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Hi Is there a specification for URL's that can be used to describe conferences ? I'd like to have such a thing to start up the mbone tools for participation in conferences (i.e.: write an external viewer shell-script to start up [rv]at/vic/wb ). Thanks Toerless From rem-conf Tue Jun 03 08:01:13 1997 From rem-conf-request@tmpmail.es.net Tue Jun 03 08:01:13 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wYuvj-0003MF-00; Tue, 3 Jun 1997 07:51:23 -0700 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Toerless Eckert cc: rem-conf@es.net Subject: Re: URL's for conferences In-reply-to: Your message of "Tue, 03 Jun 1997 16:26:34 +0200." <199706031426.QAA19634@faui40.informatik.uni-erlangen.de> Date: Tue, 03 Jun 1997 10:50:12 -0400 Message-ID: <2584.865349412@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list >Is there a specification for URL's that can be used to describe >conferences ? I'd like to have such a thing to start up the >mbone tools for participation in conferences (i.e.: write an external >viewer shell-script to start up [rv]at/vic/wb ). Two possibilities seem to make sense: 1. Use an HTTP URL to return data in MIME content-type application/sdp. Parse the description and start the tools. 2. Use an RTSP URL. The choice should be determined by whether you want RTSP-style control or not. Probably you don't need it for a conference. Mark From rem-conf Tue Jun 03 08:12:39 1997 From rem-conf-request@tmpmail.es.net Tue Jun 03 08:12:39 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wYvCX-0003lI-00; Tue, 3 Jun 1997 08:08:45 -0700 From: Toerless Eckert Message-Id: <199706031507.RAA20850@faui40.informatik.uni-erlangen.de> Subject: Re: URL's for conferences To: mjh@isi.edu (Mark Handley) Date: Tue, 3 Jun 1997 17:07:46 +0200 (MET DST) Cc: Toerless.Eckert@Informatik.Uni-Erlangen.de, rem-conf@es.net In-Reply-To: <2584.865349412@buttle.lcs.mit.edu> from "Mark Handley" at Jun 3, 97 10:50:12 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 X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list > Two possibilities seem to make sense: > > 1. Use an HTTP URL to return data in MIME content-type application/sdp. > Parse the description and start the tools. > > 2. Use an RTSP URL. > > The choice should be determined by whether you want RTSP-style control > or not. Probably you don't need it for a conference. Hi & thanks for the info. Given that conference control isn't just my hobby and that i simply want to get a URL where users who are too stupid to start "sdr" can "click on a conference" ;-) i wonder if you can point me to some place where i can steal anything if this, i.e.: a shell script to parse such a description and a sample web page that uses them. If not: Where are the specs for SDP or RTSP (and what the hell do these abbreviations mean ? ;-)) Best regards Toelress From rem-conf Tue Jun 03 08:14:52 1997 From rem-conf-request@tmpmail.es.net Tue Jun 03 08:14:52 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wYvI1-0003zS-00; Tue, 3 Jun 1997 08:14:25 -0700 Sender: hgs@cs.columbia.edu Message-ID: <339434BD.78C1@cs.columbia.edu> Date: Tue, 03 Jun 1997 11:14:05 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Mark Handley CC: Toerless Eckert , rem-conf@es.net Subject: Re: URL's for conferences References: <2584.865349412@buttle.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Mark Handley wrote: > > >Is there a specification for URL's that can be used to describe > >conferences ? I'd like to have such a thing to start up the > >mbone tools for participation in conferences (i.e.: write an external > >viewer shell-script to start up [rv]at/vic/wb ). > > Two possibilities seem to make sense: > > 1. Use an HTTP URL to return data in MIME content-type application/sdp. > Parse the description and start the tools. > > 2. Use an RTSP URL. A third choice is to use the new data: URL ftp://ietf.org/internet-drafts/draft-masinter-url-data-03.txt Unfortunately, this doesn't seem to be widely implemented yet. > > The choice should be determined by whether you want RTSP-style control > or not. Probably you don't need it for a conference. > > Mark -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs From rem-conf Tue Jun 03 08:16:25 1997 From rem-conf-request@tmpmail.es.net Tue Jun 03 08:16:25 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wYvJj-0004DJ-00; Tue, 3 Jun 1997 08:16:11 -0700 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Toerless Eckert cc: rem-conf@es.net Subject: Re: URL's for conferences In-reply-to: Your message of "Tue, 03 Jun 1997 17:07:46 +0200." <199706031507.RAA20850@faui40.informatik.uni-erlangen.de> Date: Tue, 03 Jun 1997 11:14:59 -0400 Message-ID: <2674.865350899@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list >> Two possibilities seem to make sense: >> >> 1. Use an HTTP URL to return data in MIME content-type application/sdp. >> Parse the description and start the tools. >> >> 2. Use an RTSP URL. >> >> The choice should be determined by whether you want RTSP-style control >> or not. Probably you don't need it for a conference. > >Hi & thanks for the info. > >Given that conference control isn't just my hobby and that i simply want >to get a URL where users who are too stupid to start "sdr" can "click on >a conference" ;-) i wonder if you can point me to some place where i >can steal anything if this, i.e.: a shell script to parse such a >description and a sample web page that uses them. If not: Sdr source is in ftp://cs.ucl.ac.uk/mice/sdr/ The SDP parser in sdp.tcl is one place to start. But you'll have to write quite a bit of code to take this from sdr and use it in any meaningful way. I've always intended to make the mods to sdr so you can use sdr itself as such a script, but I've not got around to it yet. >Where are the specs for SDP or RTSP (and what the hell do these >abbreviations mean ? ;-)) Session Description Protocol and Real-time Streaming Protocol. See draft-ietf-mmusic-sdp-* and draft-ietf-mmusic-rtsp-* Mark From rem-conf Tue Jun 03 08:23:54 1997 From rem-conf-request@tmpmail.es.net Tue Jun 03 08:23:53 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wYvPf-0004qO-00; Tue, 3 Jun 1997 08:22:19 -0700 From: Holger.Fahner@RUS.Uni-Stuttgart.DE (Holger Fahner) Message-Id: <9706031722.ZM29905@kssun9.rus.uni-stuttgart.de> Date: Tue, 3 Jun 1997 17:22:26 +0200 In-Reply-To: Toerless Eckert "Re: URL's for conferences" (Jun 3, 5:07pm) References: <199706031507.RAA20850@faui40.informatik.uni-erlangen.de> X-Mailer: Z-Mail (3.2.1 10apr95) To: Toerless Eckert Subject: Re: URL's for conferences Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list On Jun 3, 5:07pm, Toerless Eckert wrote: > Subject: Re: URL's for conferences > > Two possibilities seem to make sense: > > > > 1. Use an HTTP URL to return data in MIME content-type application/sdp. > > Parse the description and start the tools. > > > > 2. Use an RTSP URL. > > > > The choice should be determined by whether you want RTSP-style control > > or not. Probably you don't need it for a conference. > > Hi & thanks for the info. > > Given that conference control isn't just my hobby and that i simply want > to get a URL where users who are too stupid to start "sdr" can "click on > a conference" ;-) i wonder if you can point me to some place where i > can steal anything if this, i.e.: a shell script to parse such a > description and a sample web page that uses them. If not: Toerless, check out this one: http://www.cdt.luth.se/~peppar/progs/mSD/ I seems that they have what you are looking for, and you can even download it ;-) -- Holger -- Holger Fahner Communication Systems Phone ++49 (0) 711 685 5736 National Supercomputer Center (RUS) Fax ++49 (0) 711 678 8363 University of Stuttgart E-mail fahner@rus.uni-stuttgart.de Allmandring 3a / D-70550 Stuttgart / Germany From rem-conf Tue Jun 03 08:27:06 1997 From rem-conf-request@tmpmail.es.net Tue Jun 03 08:27:05 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wYvU2-00056P-00; Tue, 3 Jun 1997 08:26:50 -0700 Message-ID: <7D06B4AA8B39D011A64900805F682CDA019A6441@RED-09-MSG.dns.microsoft.com> From: Arlie Davis To: "'Holger.Fahner@RUS.Uni-Stuttgart.DE'" Cc: "'rem-conf@es.net'" Subject: RE: URL's for conferences Date: Tue, 3 Jun 1997 08:26:02 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.30) X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Though I haven't updated it in a while, my Win32 SD supports loading SDP descriptions from text files. It's trivial to bind the MIME type for SDP descriptions (application/x-sd, I think) to the app, with Internet Explorer or Netscape. Then all you have to do is convince your web server to serve ".sdp" files as application/x-sdp. Create SDP descriptions, save them on the web server, then point people at the URL. It works very well. The latest version (which is getting kind of stale -- yes I AM working on a new one) is available at http://archive.thepoint.net/Win32SD/ -- arlie > -----Original Message----- > From: Holger.Fahner@RUS.Uni-Stuttgart.DE > [SMTP:Holger.Fahner@RUS.Uni-Stuttgart.DE] > Sent: Tuesday, June 03, 1997 8:22 AM > To: Toerless Eckert > Cc: rem-conf@es.net > Subject: Re: URL's for conferences > > On Jun 3, 5:07pm, Toerless Eckert wrote: > > Subject: Re: URL's for conferences > > > Two possibilities seem to make sense: > > > > > > 1. Use an HTTP URL to return data in MIME content-type > application/sdp. > > > Parse the description and start the tools. > > > > > > 2. Use an RTSP URL. > > > > > > The choice should be determined by whether you want RTSP-style > control > > > or not. Probably you don't need it for a conference. > > > > Hi & thanks for the info. > > > > Given that conference control isn't just my hobby and that i simply > want > > to get a URL where users who are too stupid to start "sdr" can > "click on > > a conference" ;-) i wonder if you can point me to some place where i > > can steal anything if this, i.e.: a shell script to parse such a > > description and a sample web page that uses them. If not: > > Toerless, > > check out this one: http://www.cdt.luth.se/~peppar/progs/mSD/ > I seems that they have what you are looking for, > and you can even download it ;-) > > From rem-conf Tue Jun 03 08:41:35 1997 From rem-conf-request@tmpmail.es.net Tue Jun 03 08:41:35 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wYvev-0005gN-00; Tue, 3 Jun 1997 08:38:05 -0700 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Henning Schulzrinne cc: Toerless Eckert , rem-conf@es.net Subject: Re: URL's for conferences In-reply-to: Your message of "Tue, 03 Jun 1997 11:14:05 EDT." <339434BD.78C1@cs.columbia.edu> Date: Tue, 03 Jun 1997 11:36:46 -0400 Message-ID: <2805.865352206@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list >Mark Handley wrote: >> >Is there a specification for URL's that can be used to describe >> >conferences ? I'd like to have such a thing to start up the >> >mbone tools for participation in conferences (i.e.: write an external >> >viewer shell-script to start up [rv]at/vic/wb ). >> >> Two possibilities seem to make sense: >> >> 1. Use an HTTP URL to return data in MIME content-type application/sdp. >> Parse the description and start the tools. >> >> 2. Use an RTSP URL. > >A third choice is to use the new data: URL >ftp://ietf.org/internet-drafts/draft-masinter-url-data-03.txt I tend to believe this is a bad idea. Yes, in principle you can code anything in a (very long) URL. But in practice there are advantages to be gained from a URL being a reference and not a description. It makes it much easier for the "owner" of the data to modify it and its description without invalidating URL's to the session scattered throughout the net. Mark From rem-conf Tue Jun 03 09:43:33 1997 From rem-conf-request@tmpmail.es.net Tue Jun 03 09:43:33 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wYwcz-0006T4-00; Tue, 3 Jun 1997 09:40:09 -0700 Message-Id: <199706031639.MAA09644@zubin.dnrc.bell-labs.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Mark Handley cc: rem-conf@es.net Subject: Re: URL's for conferences In-reply-to: Your message of "Tue, 03 Jun 1997 11:36:46 EDT." <2805.865352206@buttle.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Jun 1997 12:39:14 -0400 From: Zheng Wang X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list > 1. Use an HTTP URL to return data in MIME content-type application/sdp. > Parse the description and start the tools. Would it be a good idea to extend the concept of a session to other applications such as ftp, telnet, well any applications? So we can have a platform/OS independent description of how one can start any application (and maybe doing a few operations). I think this would be a right drection towards a www/browser-based general use interface. Cheers Zheng From rem-conf Tue Jun 03 10:49:26 1997 From rem-conf-request@tmpmail.es.net Tue Jun 03 10:49:25 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wYxc0-000779-00; Tue, 3 Jun 1997 10:43:12 -0700 Message-Id: <3.0.32.19970603133301.04aaf2e8@mailee.bellcore.com> X-Sender: stanm@mailee.bellcore.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 03 Jun 1997 13:33:15 -0400 To: enternet@bbn.com, tccc@cs.umass.edu, dbworld@cs.wisc.edu, end2end-interest@isi.edu, f-troup@CODEX.CIS.UPENN.EDU, cost237-transport@comp.lancs.ac.uk, reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, cellular@comnets.rwth-aachen.de, ieeetcpc@ccvm.sunysb.edu, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comswtc@gmu.edu, giga@tele.pitt.edu, multicomm@cc.bellcore.com From: Stan Moyer Subject: Call for Papers -- ENCOM '98 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list CALL FOR PAPERS Enterprise Networking and Computing '98 (ENCOM-98) in conjunction with ICC/SuperComm '98 (June7-11), Atlanta, Georgia, Thursday, June 11 ENCOM-98 will provide an open forum for the enterprise networking and computing communities to review new and emerging technologies, services, and their implications from both business and technological viewpoints. The objective is to bridge the gap between: (a) Enterprise-wide business drivers and (b) Technology- driven solutions and enablers. The conference will include a keynote speech, panel discussions, and paper sessions by leaders, recognized experts and active researchers in the field. Submission Instructions ----------------------- The title page must include the corresponding author's full name, complete postal and e-mail addresses, telephone and fax numbers, and a 200-word abstract. Five double-spaced copies of papers (12 point times font, maximum 3000 words) on 8.5"x11" or A4 papers should be sent to the ENCOM-98 technical chair at the address given below. All submissions will be peer-reviewed and the accepted papers will be published in the proceedings of ENCOM-98. Proposals for panels should be submitted to the panel discussion arrangement chair. Schedule: --------- Complete Manuscript Due: 15 November 1997 Acceptance Note Mailed: 01 February 1998 Camera-ready Paper Due: 01 March 1998 Hot topics: ----------- o Utilization of new and emerging technologies for the evolution of enterprise networks o Intranets, Extranets and Internets: How they are transforming the enterprise networks o Legacy systems integration o Integration of enterprise network subsystems to provide "end-user" oriented services o Enterprise network application/services integration o Internetworking and interoperability of enterprise network components o Enterprise-wide computing, including distributed applications, client-serving computing, etc. o Enterprise information resource management. o Enterprise network management o Business processes re-engineering enterprise networks o Pros and cons of enterprise network outsourcing o Integration of network and systems management from an enterprise viewpoint. General Chair: -------------- Bhumip Khasnabish (bhumip@gte.com), MA, USA Technical Chair: ---------------- Vijay K. Bhagavath (bhagavath@att.com) AT&T Laboratories, Rm. 1L-333 101 Crawfords Corner Rd., Holmdel, NJ 07733, USA Tel: +1-908-949-2837, Fax: +1-908-949-4852 Panels Chair: ------------- Manu Malek (mmalek@lucent.com) For more information, see: -------------------------- http://www.comsoc.org/confs/encom/98 Sponsored by the IEEE Communications Society Technical Committee on Enterprise Networking From rem-conf Tue Jun 03 13:40:18 1997 From rem-conf-request@tmpmail.es.net Tue Jun 03 13:40:17 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZ094-000103-00; Tue, 3 Jun 1997 13:25:30 -0700 Date: Tue, 3 Jun 1997 16:25:15 -0400 (EDT) Message-Id: <199706032025.QAA08620@snad.ncsl.nist.gov> To: zhwang@dnrc.bell-labs.com Subject: Re: URL's for conferences Cc: rem-conf@es.net From: wchang@nist.gov (Wo Chang, x3439) X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Zheng Wang wrote: > > Would it be a good idea to extend the concept of a session to other > applications such as ftp, telnet, well any applications? So we can > have a platform/OS independent description of how one can start any > application (and maybe doing a few operations). I think this would > be a right drection towards a www/browser-based general use interface. I strongly agreed with platform/OS independent description environment with a browser-based as the general interface. This provides any user to see what activities are being or will be multicasted even if a user does not have the multicast kernel running. In addition, it allows network administrator to check the MBone feed status since if there is no MBone traffic, there will not be any SDR entries (after the expiration period). A character based (something like curses) front-end would also be helpful, at the worst case, network administrator can always telnet to a multicast host to run the curses-based sdr to check the MBone feed status. At NIST (National Institute of Standards and Technology), we are very interested on Multicast/MBone measurement and performance statistics. Currently, we're developing an integrated performance package that will listening to SAP/SDP packets for the sdr entry (as well as allow user to specify a specific mulitcast address/port) and by selecting a particular sdr entry we then use RTP/RTCP packets to gather multicast audio/video stream performance statistics (just like the rtpmon). Initially, it will be a character-based so it can offer remote telnet, and in addition, by changing its output to html format, it could serve from a web server. At the second phase (once we have a better understanding on what to measure), change the output portion into a java-based applet so a continuous graphs can be presented as well as avoiding a full page html reload for the delta performance statistics. The final phase is to have the whole performance package written in a java applet, so the entire performance tool will be running locally at the user side. This way, user can see the MBone performance statistics at his/her own subnet instead looking at the web server subnet. [NOTE: there might be a problem running multicast within an applet, I have tried MS IE 3.x and Netscape 3.x with JDK 1.02 and MS IE 4.0 Preview with JDK 1.1.x, nothing works, but multicast under java application works. Any comments and thoughs? ] Actually, all 3 phases have its own usefulness which depends on how you access (via telnet or browser) and what to access (local multicast statistics or remote multicast statistics). Currently, I have completed 70% of the first phase and it runs under both SunOS 4.1.x and Solaris 2.5.x. Comments and thoughts on the above approaches would be greatly appreciated. --Wo Chang From rem-conf Tue Jun 03 14:01:38 1997 From rem-conf-request@tmpmail.es.net Tue Jun 03 14:01:37 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZ0gb-0001WJ-00; Tue, 3 Jun 1997 14:00:09 -0700 Message-Id: <3.0.1.32.19970603165951.00b076d0@cis.gsu.edu> X-Sender: rpadilla@cis.gsu.edu X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 03 Jun 1997 16:59:51 -0400 To: rem-conf@es.net From: Roderick Padilla Subject: Lost Sessions In-Reply-To: <199706032025.QAA08620@snad.ncsl.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list I created a test session for GA State and after exiting sdr I could not see it anymore. I created a second test to duplicate the problem and diag and now I can not see it. Any ideas? I am using sdr 2.3a1 for Solaris 2.4. The second test will expire in a couple of hours. Thanks! Roderick Padilla Office:(404) 651-3832 Systems & Network Administrator Fax: (404) 651-3842 http://www.cis.gsu.edu/~rpadilla Email: rpadilla@gsu.edu Department of Computer Information Systems College of Business Administration Georgia State University PO Box 4015 Atlanta, Georgia, USA 30302-4015 From rem-conf Tue Jun 03 14:37:59 1997 From rem-conf-request@tmpmail.es.net Tue Jun 03 14:37:58 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZ1BQ-000238-00; Tue, 3 Jun 1997 14:32:00 -0700 Date: Tue, 3 Jun 97 14:30:44 PDT From: schooler@cs.caltech.edu (Eve Schooler) Message-Id: <9706032130.AA08404@vlsi.cs.caltech.edu> To: rpadilla@gsu.edu Subject: Re: Lost Sessions Cc: schooler@cs.caltech.edu, rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list >From rem-conf-request@tmpmail.es.net Tue Jun 3 14:07:45 1997 >X-Sender: rpadilla@cis.gsu.edu >Date: Tue, 03 Jun 1997 16:59:51 -0400 >To: rem-conf@es.net >From: Roderick Padilla >Subject: Lost Sessions > >I created a test session for GA State and after exiting sdr I could not see >it anymore. I created a second test to duplicate the problem and diag and >now I can not see it. Any ideas? > >I am using sdr 2.3a1 for Solaris 2.4. The second test will expire in a >couple of hours. > >Roderick Padilla Office:(404) 651-3832 My understanding is that if you create a session in sdr, then YOUR sdr application is responsible for sending the announcements that periodically renew the session's existence -- until the end of the session as specified in the description. If you exit out of the sdr that was used to create the session, then you have effectively deleted the session. Not sure if your local sdr will ever resume announcing a session that you created but exited out of, if for instance sdr cached the entry and the session is still valid? E. From rem-conf Wed Jun 04 07:13:32 1997 From rem-conf-request@tmpmail.es.net Wed Jun 04 07:13:32 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZGak-0005EW-00; Wed, 4 Jun 1997 06:59:10 -0700 From: "Ian McComb" Organization: SML, University of Southampton To: rem-conf@tmpmail.es.net Date: Wed, 4 Jun 1997 14:55:52 GMT Subject: Losing fps when rat + vic run together Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Message-ID: <27617965593@lang.soton.ac.uk> X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list I have a problem using the MBone software rat 3.0.22 + vic 2.8 for Windows 95. When vic is running on its own I can get 6,7,8 fps and 150 - 300 Kbps. When rat is started (or any other program on my machine eg email or netscape) the fps starts going down and averages out about 1 fps. If I close the software the fps comes back up. Rat works well on its own or with vic. Is this what happens or do I have a bottleneck somewhere. We have monitored the network and we feel that at most we are using 10 percent. The computer configuration is, 200 MHz Pentium 64MB RAM 2MB Diamond Stealth 64 PCI graphics card Videolabs stinger card Videolabs Flexcam or Composite Video from recorder Sond blaster 16 Our MBone router is a Sun Sparc 4, the software used is Mrouted. I would be very grateful for any help. Ian --------------------------------------------------------- Ian McComb School of Modern Languages University of Southampton SO17 1BF Email - I.McComb@lang.soton.ac.uk Phone - 01703 593978 From rem-conf Wed Jun 04 07:47:13 1997 From rem-conf-request@tmpmail.es.net Wed Jun 04 07:47:13 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZHEU-0005hf-00; Wed, 4 Jun 1997 07:40:14 -0700 Date: Wed, 4 Jun 1997 10:38:01 -0400 From: luigi@mars.dgrc.doc.ca (John A. Stewart) Message-Id: <199706041438.KAA00989@barney.dgrc.doc.ca> To: rem-conf@tmpmail.es.net, I.McComb@LANG.SOTON.AC.UK Subject: Re: Losing fps when rat + vic run together X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Ian; on our Sun workstations at work, and on my Linux '486 at home, vic ties up the cpu. ie, it is 100% busy processing video. When you start something else, less of that cpu is available to vic. fyi, my 486 DX4-100, running Linux with a black and white Quickcam runs 4-6 fps, and it takes 100% of the system cpu. When I start something else, the frame rate drops, but I think that drop is never more than about 50% (say, if I have a compile started) I have heard that multitasking on Windows-95 is not so good, so if you start up more, you get much less... So, the drop is to be expected, but I would have thought that the drop would not have been so great as you reported. There are many people with Windows-95 boxes, hopefully someone else with more direct experience will reply. John Stewart luigi@mars.dgrc.doc.ca ----- Begin Included Message ----- >From rem-conf-request@tmpmail.es.net Wed Jun 4 10:15:37 1997 From: "Ian McComb" I have a problem using the MBone software rat 3.0.22 + vic 2.8 for Windows 95. When vic is running on its own I can get 6,7,8 fps and 150 - 300 Kbps. When rat is started (or any other program on my machine eg email or netscape) the fps starts going down and averages out about 1 fps. If I close the software the fps comes back up. Rat works well on its own or with vic. Is this what happens or do I have a bottleneck somewhere. We have monitored the network and we feel that at most we are using 10 percent. From rem-conf Wed Jun 04 08:42:37 1997 From rem-conf-request@tmpmail.es.net Wed Jun 04 08:42:37 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZI5T-0006DI-00; Wed, 4 Jun 1997 08:34:59 -0700 Message-Id: <199706041534.IAA06288@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: luigi@mars.dgrc.doc.ca (John A. Stewart) cc: rem-conf@tmpmail.es.net, I.McComb@LANG.SOTON.AC.UK Subject: Re: Losing fps when rat + vic run together In-reply-to: Your message of "Wed, 04 Jun 1997 10:38:01 EDT." <199706041438.KAA00989@barney.dgrc.doc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Jun 1997 08:34:55 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list >From The Desk Of John A. Stewart : > Ian; > I have heard that multitasking on Windows-95 is not so good, so if you > start up more, you get much less... > > So, the drop is to be expected, but I would have thought that the drop > would not have been so great as you reported. > > There are many people with Windows-95 boxes, hopefully someone else with > more direct experience will reply. > Video for Windows is not necessarily the highest performance api nor the the interface which vic uses to diplay . You probably want when available to use DirectX and have the cards do the YUV to RGB conversion. As for Video for Windows performance, the upcoming WDM drivers and and ActiveMovie should take care of the video processiong bottleneck. Amancio From rem-conf Wed Jun 04 10:46:27 1997 From rem-conf-request@tmpmail.es.net Wed Jun 04 10:46:27 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZK1S-000762-00; Wed, 4 Jun 1997 10:38:58 -0700 From: Scott_Petrack@vocaltec.com X-Lotus-FromDomain: VOCALTEC To: casner@precept.com cc: rem-conf@es.net Message-ID: Date: Wed, 4 Jun 1997 20:25:53 +0200 Subject: Overriding a defined static payload type Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Scott Petrack 06/04/97 07:25 PM This was written a few weeks ago, but I just got a note from my Notes server saying that it didn't get send. Damn this Notes.... Steve, I would like to suggest a small change to the RTP text to allow the dynamic payload types to override the static types if there is a need in a single session for more than the number of dynamic payload types available. Here are my reasons: 1. With layered encodings becoming more and more important, and bandwidth becoming more and more avaiable, I can see a situation where a single session might need a lot of different payload types. Already a group of 8 or 10 participants using different layered codecs might need too many dynamic payload types. 2. There are undoubtedly many coders in the basic A/V profile which will not be very popular not too many years from now. It would be a shame to have to write a new profile just because these by-then-obsolete coders take up room in the payload type space. 3. Such a change will not break anything that exists now. Of course it may be that if this problem ever actually appears, consenting applications will just override the static types anyway. But it seems that with this tiny change we can enable future applications to be compliant with the basic A/V profile, even if they require lots of payload types to support layered encodings. Sincerely, Scott Petrack From rem-conf Wed Jun 04 21:56:05 1997 From rem-conf-request@tmpmail.es.net Wed Jun 04 21:56:04 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZUSm-0001E6-00; Wed, 4 Jun 1997 21:47:52 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Wed, 4 Jun 1997 21:46:38 -0700 (PDT) Message-Id: <199706050446.VAA10114@hille.msri.org> To: rem-conf@es.net From: mc-mbone Reply-to: mc-mbone@iij-mc.co.jp Subject: Sapporo YOSAKOI Festival X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Sapporo YOSAKOI Festival Date: Jun 07, 1997 Time: 03:00 GMT 12 hours Contact: mc-mbone@iij-mc.co.jp URL: http://www.iij-mc.co.jp/MBone/ Description: YOSAKOI Festival realtime transmission from Sapporo, Japan. We will use IP/TV server for encoding, but vic/vat can receive. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Jun 05 00:16:46 1997 From rem-conf-request@tmpmail.es.net Thu Jun 05 00:16:46 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZWhK-0001qd-00; Thu, 5 Jun 1997 00:11:02 -0700 Date: Thu, 5 Jun 1997 09:09:53 +0200 (MET DST) From: Christoph Fleck X-Sender: fleck@rncmm1 Reply-To: Referenzzentrum fuer multimediale Teledienste To: Ian McComb cc: rem-conf@tmpmail.es.net Subject: Re: Losing fps when rat + vic run together In-Reply-To: <27617965593@lang.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Hi Ian, I have used rat3.0.22 and the Win95-System-Monitor say that 70% of CPU is used. I have used rat on some diffrent PCs (P5/90 P5/166 4/100) but there was no Diffrence. Always 70% CPU. So I belive that rat (Version 3.0.22 and 3.0.20) waste with your CPU. About the other Progs. i dont know. Try rat 2.6 that dont waste CPU that much (but has some bug) to check your vic. (or vat but it is still half-duplex on Win95) rgs Christoph ,------------------------------------------------------------------. | Referenzzentrum fuer multimediale Teledienste (MMRZ), TU Dresden | | Dr. Klaus Koehler, Christoph Fleck, Rainer Kranz | | e-mail: mmt-ref@tu-dresden.de Tel.: 0351 / 463 5653 | | WWW: http://www-mm.urz.tu-dresden.de (GERMANY) | `------------------------------------------------------------------' On Wed, 4 Jun 1997, Ian McComb wrote: > I have a problem using the MBone software rat 3.0.22 + vic 2.8 > for Windows 95. When vic is running on its own I can get 6,7,8 > fps and 150 - 300 Kbps. When rat is started (or any other > program on my machine eg email or netscape) the fps starts > going down and averages out about 1 fps. If I close the > software the fps comes back up. Rat works well on its own or > with vic. Is this what happens or do I have a bottleneck > somewhere. We have monitored the network and we feel that at > most we are using 10 percent. > > The computer configuration is, > > 200 MHz Pentium > 64MB RAM > 2MB Diamond Stealth 64 PCI graphics card > Videolabs stinger card > Videolabs Flexcam or Composite Video from recorder > Sond blaster 16 > > Our MBone router is a Sun Sparc 4, the software used is Mrouted. > > I would be very grateful for any help. > > Ian > > --------------------------------------------------------- > Ian McComb > > School of Modern Languages > University of Southampton > SO17 1BF > > Email - I.McComb@lang.soton.ac.uk > Phone - 01703 593978 > > From rem-conf Thu Jun 05 01:10:12 1997 From rem-conf-request@tmpmail.es.net Thu Jun 05 01:10:10 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZXbH-0002Ix-00; Thu, 5 Jun 1997 01:08:51 -0700 From: "Ian McComb" Organization: SML, University of Southampton To: Steve Hopper Date: Thu, 5 Jun 1997 09:05:51 GMT Subject: Re: Losing fps when rat + vic run together CC: rem-conf@tmpmail.es.net Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Message-ID: <28842A35A92@lang.soton.ac.uk> X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list > Hi, > > Are any of you able to create a new session using Windows 95 and sdr? I > get a variety of results when attempting this. Mainly, after entering > the options and parameters, then selecting OK, the sdr session quits and > nothing is announced. > > Pentium200 > SDR UCL 2.1a10 > Hi Steve Try sdrwin (ftp://cs.ucl.ac.uk/mice/sdrtest/). I find it works very well. If it does start to produce error messages delete prefs file restart and enter information in prefs again. I had to do this a couple of times but in general its fine. Ian --------------------------------------------------------- Ian McComb School of Modern Languages University of Southampton SO17 1BF Email - I.McComb@lang.soton.ac.uk Phone - 01703 593978 From rem-conf Thu Jun 05 03:44:21 1997 From rem-conf-request@tmpmail.es.net Thu Jun 05 03:44:18 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZZxZ-0002tR-00; Thu, 5 Jun 1997 03:40:01 -0700 X-Authentication-Warning: dxmint.cern.ch: Host hel3sn03.cern.ch [137.138.211.123] claimed to be hpl3sn03.cern.ch Sender: hgalvez@cern.ch Message-Id: <3396976A.7B38@cern.ch> Date: Thu, 05 Jun 1997 12:39:38 +0200 From: Philippe GALVEZ Organization: CERN. European Lab. for Particle Physics X-Mailer: Mozilla 3.01Gold (X11; I; HP-UX A.09.03 9000/712) Mime-Version: 1.0 To: "H.A. Kippenhan Jr." Cc: rem-conf@es.net, kippenhan@hep.net, philippe.galvez@cern.ch Subject: Re: 640x480 support in VIC when using nv encoding References: Content-Type: multipart/mixed; boundary="------------27744461415E" X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list This is a multi-part message in MIME format. --------------27744461415E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit H.A. Kippenhan Jr. wrote: > I've tried using vic (as a replacement for nv) on a small number > of Sun and SGI workstations. When using nv, I can transmit a > picture of 640x480 size. When using vic (and it's nv compatibility > encoding) I find I can't transmit the 640x480 image size. Hi Kipp, I sent last year to Van and Steve modified codes to allow: - Full video size support vith vic using nv, nvdct, cellb with SGI irix5.3 - Video voice switch at the source node (See later) but I suppose their "To do" list should be quite big. Anyway, you will found at the end a modified version of grabber-vl.cc file So, just replace it on the source distribution with the new one, compile and it should work fine. Concerning "Video voice switch" I make some small modification to the files: ui-ctrlmemu.tcl ui-main.tcl ui-resource.tcl ui-switcher.tcl We obtained the following feature: Allowing a Real voice switch at the source node. I defined 2 more Ressources paramaters in Vic. - One correspond to the maximun video bandwith allowed for all the participants : maxConfBand (defined at 200 kbps by default) - Second is the percent of this maximun bandwith permits to the speaker : percentForSpeaker (defined at 90% by default) So at the end when you speak, vic will limite automatically your Maximun bandwith limitation set to : [(maxConfBand x percentForSpeaker)/100] That will be 180 kbps by default. And if you don't speak because someonelse is speaking, vic limites automatically your vic video bandwith at a maximun of: [maxConfBand - ((maxConfBand x percentForSpeaker)/100)) / (nbre of passive participant)] That will be 20 kbps by default for 2 particants, 10 kbps for 3 participants and so one.. So, we will have always a total a maximun of maxConfBand kbps/s for for all video streams within the conference and this whatever the number of participants all sending video. If everybody is well configured, you can have in theorie infinite video flux. Please, note that defining the parameter percentForSpeaker equal to 100 imply total video switch (nothing is transmitted if you are note the speaker). By the way it is more pleasant to receive all video flux even if all of them (except the speaker) will be sent at a very low bandwith and then very low frame rate. Please, any comments are welcome. So, for people interested, I can distribuated the modified source code. Best Regards, Philippe Galvez Caltech/CERN --------------27744461415E Content-Type: text/plain; charset=us-ascii; name="grabber-vl.cc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="grabber-vl.cc" /* * Copyright (c) 1993-1994 Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and the Network Research Group at * Lawrence Berkeley Laboratory. * 4. Neither the name of the University nor of the Laboratory may be used * to endorse or promote products derived from this software without * specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ #ifndef lint static char rcsid[] = "@(#) $Header: grabber-vl.cc,v 1.50 95/12/03 22:41:47 mccanne Exp $ (LBL)"; #endif #include #include #include #include #include #include #include #include #include #include "grabber.h" #include "crdef.h" #include "module.h" #include "device-input.h" #include "Tcl.h" class vlDevice; class VLGrabber : public Grabber { public: VLGrabber(vlDevice&); virtual ~VLGrabber(); virtual int command(int argc, const char*const* argv); virtual void fps(int); virtual void start(); virtual void stop(); protected: void startup_vl(); void shutdown_vl(); virtual void saveblks(const u_char*); void suppress(const u_char*); virtual int grab(); virtual void setsize(int xsize, int ysize); u_char* next_frame(); int closest_rate(int fps) const; VLServer vlServer_; VLPath vlPath_; VLBuffer transferBuf_; VLNode src_; VLNode drn_; int decimate_; int current_decimate_; int current_fps_; int current_port_; int is_pal_; int port_; vlDevice& device_; }; class VLCIFGrabber : public VLGrabber { public: VLCIFGrabber(vlDevice&); protected: virtual void setsize(int xsize, int ysize); void saveblk(const u_char* in, u_char* yp, u_char* up, u_char* vp, int stride, int is); virtual void saveblks(const u_char* in); }; class VL411Grabber : public VLCIFGrabber { public: VL411Grabber(vlDevice&); protected: virtual void setsize(int xsize, int ysize); }; class vlDevice : public InputDevice { public: vlDevice(const char* name, VLDev, VLNodeInfo* ports, int nport); virtual int command(int argc, const char*const* argv); inline int device() const { return (device_); } int lookup_port(const char*) const; protected: VLDev device_; VLNodeInfo* ports_; int nport_; }; static class vlBuilder { public: vlBuilder(); static VLNodeInfo* findports(VLNodeInfo* node, int& n); } vlb; vlDevice::vlDevice(const char* name, VLDev device, VLNodeInfo* ports, int nport) : InputDevice(name), device_(device), ports_(ports), nport_(nport) { /* smash "ev1" insto galileo for better familiarity */ if (nickname_[0] == 'e' && nickname_[1] == 'v') { nickname_ = "galileo"; } char* cp = new char[80 + nport * (VL_NAME_SIZE + 1)]; attributes_ = cp; strcpy(cp, "format { 411 422 422} size { small cif large } port { "); cp += strlen(cp); *cp++ = ' '; for (int i = 0; i < nport; ++i) { strcpy(cp, ports[i].name); cp += strlen(cp); *cp++ = ' '; } *cp++ = '}'; *cp = 0; } int vlDevice::lookup_port(const char* name) const { for (int i = 0; i < nport_; ++i) { if (strcasecmp(name, ports_[i].name) == 0) return (ports_[i].number); } abort(); } int vlDevice::command(int argc, const char*const* argv) { Tcl& tcl = Tcl::instance(); if (argc == 3) { if (strcmp(argv[1], "open") == 0) { TclObject* o = 0; if (strcmp(argv[2], "422") == 0) o = new VLGrabber(*this); else if (strcmp(argv[2], "411") == 0) o = new VL411Grabber(*this); else if (strcmp(argv[2], "cif") == 0) o = new VLCIFGrabber(*this); if (o != 0) tcl.result(o->name()); return (TCL_OK); } } return (InputDevice::command(argc, argv)); } vlBuilder::vlBuilder() { VLServer s = vlOpenVideo(""); if (s == 0) return; VLDevList devlist; if (vlGetDeviceList(s, &devlist) == 0) { for (int i = 0; i < devlist.numDevices; ++i) { VLDevice* p = &devlist.devices[i]; int n = p->numNodes; VLNodeInfo* ni = findports(p->nodes, n); if (n > 0) new vlDevice(p->name, p->dev, ni, n); } } vlCloseVideo(s); } /* * Lookup all video sources and smash spaces in names to dashes * to avoid tcl list problems. */ VLNodeInfo* vlBuilder::findports(VLNodeInfo* node, int& n) { VLNodeInfo* result = new VLNodeInfo[n]; int k = 0; for (int i = 0; i < n; ++i) { if (node[i].type == VL_SRC && node[i].kind == VL_VIDEO) { result[k] = node[i]; for (char* cp = result[k].name; *cp != 0; ++cp) if (isspace(*cp)) *cp = '-'; ++k; } } n = k; return (result); } u_char* VLGrabber::next_frame() { register u_char* p = 0; if (vlServer_ && transferBuf_) { /* * wait at most one frame time (30ms) for a frame to show up. */ VLInfoPtr info = 0; for (register int i = 3; --i >= 0; ) { info = vlGetLatestValid(vlServer_, transferBuf_); if (info != 0) break; sginap(1); } if (info) { p = (u_char*)vlGetActiveRegion(vlServer_, transferBuf_, info); if (p == NULL) vlPerror("vic: vlGetActiveRegion"); } } return (p); } /* 422 */ inline void saveblk(const u_char* in, u_char* yp, u_char* up, u_char* vp, int stride) { int is = stride << 2; int cs = stride >> 1; for (int i = 16; --i >= 0; ) { /* * Each iteration of this loop grabs 16 Ys & 8 U/Vs. */ register u_int y0, y1, u, v; u = in[0] << 24 | in[8] << 16 | in[16] << 8 | in[24]; v = in[2] << 24 | in[10] << 16 | in[18] << 8 | in[26]; y0 = in[1] << 24 | in[5] << 16 | in[9] << 8 | in[13]; y1 = in[17] << 24 | in[21] << 16 | in[25] << 8 | in[29]; ((u_int*)yp)[0] = y0; ((u_int*)yp)[1] = y1; *(u_int*)up = u; *(u_int*)vp = v; u = in[32+0] << 24 | in[32+8] << 16 | in[32+16] << 8 | in[32+24]; v = in[32+2] << 24 | in[32+10] << 16 | in[32+18] << 8 | in[32+26]; y0 = in[32+1] << 24 | in[32+5] << 16 | in[32+9] << 8 | in[32+13]; y1 = in[32+17] << 24 | in[32+21] << 16 | in[32+25] << 8 | in[32+29]; ((u_int*)yp)[2] = y0; ((u_int*)yp)[3] = y1; ((u_int*)up)[1] = u; ((u_int*)vp)[1] = v; in += is; yp += stride; up += cs; vp += cs; } } /* 422 NEW */ inline void saveblk_large(const u_char* in, u_char* yp, u_char* up, u_char* vp, int stride) { int is = stride << 2; int cs = stride >> 1; for (int i = 16; --i >= 0; ) { /* * Each iteration of this loop grabs 16 Ys & 8 U/Vs. */ register u_int y0, y1, u, v; u = in[0] << 24 | in[4] << 16 | in[8] << 8 | in[12]; v = in[2] << 24 | in[6] << 16 | in[10] << 8 | in[14]; y0 = in[1] << 24 | in[3] << 16 | in[5] << 8 | in[7]; y1 = in[9] << 24 | in[11] << 16 | in[13] << 8 | in[15]; ((u_int*)yp)[0] = y0; ((u_int*)yp)[1] = y1; *(u_int*)up = u; *(u_int*)vp = v; u = in[16+0] << 24 | in[16+4] << 16 | in[16+8] << 8 | in[16+12]; v = in[16+2] << 24 | in[16+6] << 16 | in[16+10] << 8 | in[16+14]; y0 = in[16+1] << 24 | in[16+3] << 16 | in[16+5] << 8 | in[16+7]; y1 = in[16+9] << 24 | in[16+11] << 16 | in[16+13] << 8 | in[16+15]; ((u_int*)yp)[2] = y0; ((u_int*)yp)[3] = y1; ((u_int*)up)[1] = u; ((u_int*)vp)[1] = v; in += is/2; yp += stride; up += cs; vp += cs; } } void VLGrabber::saveblks(const u_char* in) { /**NEW**/ const u_int8_t* crv = crvec_; u_int8_t* yp = frame_; u_int8_t* up = yp + framesize_; u_int off = framesize_ >> 1; int stride = 15 * outw_; int stride1 = stride / 2 ; for (int y = 0; y < blkh_; ++y) { for (int x = 0; x < blkw_; ++x) { int s = *crv++; /* Not clever way to check Large image but anyway */ if (outw_ < 600) { if ((s & CR_SEND) != 0) saveblk(in, yp, up, up + off, outw_); in += 64; } else { if ((s & CR_SEND) != 0) saveblk_large(in, yp, up, up + off, outw_); in += 32; } yp += 16; up += 8; } yp += stride; up += stride >> 1; if (outw_ > 400) in += stride1 << 2; else in += stride << 2; } } /* * define these for REPLENISH macro used below */ /* With again not clever way to check Large image but anyway */ #define DIFF4(in, frm, v, nume) \ v += (in)[1] - (frm)[0]; \ v += (in)[3+nume] - (frm)[1]; \ v += (in)[5+2*nume] - (frm)[2]; \ v += (in)[7+3*nume] - (frm)[3]; #define DIFFLINE(in, frm, left, center, right) \ if (outw_ < 600) { \ DIFF4(in, frm, left, 2); \ DIFF4(in + 1*16, frm + 1*4, center, 2); \ DIFF4(in + 2*16, frm + 2*4, center, 2); \ DIFF4(in + 3*16, frm + 3*4, right, 2); \ }else{\ DIFF4(in, frm, left, 0); \ DIFF4(in + 1*8, frm + 1*4, center, 0); \ DIFF4(in + 2*8, frm + 2*4, center, 0); \ DIFF4(in + 3*8, frm + 3*4, right, 0); \ }\ \ if (right < 0) \ right = -right; \ if (left < 0) \ left = -left; \ if (center < 0) \ center = -center; void VLGrabber::suppress(const u_char* devbuf) { const u_char* start = frame_ + 16 * vstart_ * outw_ + 16 * hstart_; /* Not clever way to check Large image but anyway */ if (outw_ < 600) { REPLENISH(devbuf, start, inw_ << 2 , 4, hstart_, hstop_, vstart_, vstop_); } else { REPLENISH(devbuf, start, (inw_/2) << 2 , 2, hstart_, hstop_, vstart_, vstop_); } } int VLGrabber::grab() { u_char* p = next_frame(); if (p == 0) return (0); suppress(p); saveblks(p); vlPutFree(vlServer_, transferBuf_); YuvFrame f(media_ts(), frame_, crvec_, outw_, outh_); return (target_->consume(&f)); } void VLGrabber::setsize(int w, int h) { set_size_422(w, h); } int VLGrabber::command(int argc, const char*const* argv) { if (argc == 3) { if (strcmp(argv[1], "decimate") == 0) { int d = atoi(argv[2]); Tcl& tcl = Tcl::instance(); if (d <= 0) { tcl.result("divide by zero"); return (TCL_ERROR); } decimate_ = d; startup_vl(); return (TCL_OK); } if (strcmp(argv[1], "port") == 0) { port_ = device_.lookup_port(argv[2]); startup_vl(); return (TCL_OK); } } return (Grabber::command(argc, argv)); } void VLGrabber::start() { startup_vl(); Grabber::start(); } void VLGrabber::stop() { shutdown_vl(); Grabber::stop(); } void VLGrabber::fps(int f) { Grabber::fps(f); startup_vl(); } void VLGrabber::shutdown_vl() { if (vlServer_) { if (vlPath_) { if (transferBuf_) { vlEndTransfer(vlServer_, vlPath_); vlDeregisterBuffer(vlServer_, vlPath_, drn_, transferBuf_); vlDestroyBuffer(vlServer_, transferBuf_); transferBuf_ = 0; } vlDestroyPath(vlServer_, vlPath_); vlPath_ = 0; } vlCloseVideo(vlServer_); vlServer_ = 0; } } static int vl_ntsc_rates[] = { 30, 25, 24, 20, 18, 15, 12, 10, 6, 5 }; static int vl_pal_rates[] = { 25, 20, 15, 10, 5 }; int VLGrabber::closest_rate(int fps) const { if (fps <= 5) return (5); int* rate = is_pal_ ? vl_pal_rates : vl_ntsc_rates; while (rate[1] > fps) ++rate; return (*rate); } void VLGrabber::startup_vl() { if (vlServer_ != 0 && decimate_ == current_decimate_ && fps_ == current_fps_ && port_ == current_port_) return; current_decimate_ = decimate_; current_fps_ = fps_; current_port_ = port_; shutdown_vl(); VLControlValue val; int xsize; int ysize; vlServer_ = vlOpenVideo(""); if (vlServer_ == 0) goto failed; src_ = vlGetNode(vlServer_, VL_SRC, VL_VIDEO, port_); drn_ = vlGetNode(vlServer_, VL_DRN, VL_MEM, VL_ANY); vlPath_ = vlCreatePath(vlServer_, device_.device(), src_, drn_); if (vlPath_ < 0) { vlPerror("vic: create path"); goto failed; } if (vlSetupPaths(vlServer_, (VLPathList)&vlPath_, 1, VL_SHARE, VL_SHARE) < 0) { vlPerror("vic: set up paths"); goto failed; } val.intVal = VL_PACKING_YVYU_422_8; if (vlSetControl(vlServer_, vlPath_, drn_, VL_PACKING, &val) < 0) { vlPerror("vic: set control packing"); goto failed; } vlGetControl(vlServer_, vlPath_, drn_, VL_SIZE, &val); xsize = val.xyVal.x; ysize = val.xyVal.y &~ 7; if (xsize != 640) /*XXX there must be a better way */ is_pal_ = 1; else is_pal_ = 0; xsize /= decimate_; ysize /= decimate_; val.fractVal.numerator = closest_rate(fps_); val.fractVal.denominator = 1; if (vlSetControl(vlServer_, vlPath_, drn_, VL_RATE, &val) < 0) vlPerror("vic: set rate"); val.intVal = decimate_ == 1? VL_CAPTURE_INTERLEAVED : VL_CAPTURE_EVEN_FIELDS; if (vlSetControl(vlServer_, vlPath_, drn_, VL_CAP_TYPE, &val) < 0) { vlPerror("vic: vl set captype"); goto failed; } if (decimate_ != 1) { val.fractVal.numerator = 1; val.fractVal.denominator = decimate_ >> 1; if (vlSetControl(vlServer_, vlPath_, drn_, VL_ZOOM, &val) < 0) vlPerror("vic: zoom"); } /* Create ring buffers to hold captured data of new size. */ transferBuf_ = vlCreateBuffer(vlServer_, vlPath_, drn_, 2); if (transferBuf_ == 0) { vlPerror("vic: create Buffer"); goto failed; } /* Tell VL to use newly created ring buffer. */ if (vlRegisterBuffer(vlServer_, vlPath_, drn_, transferBuf_) < 0) { vlPerror("vic: buffer registration"); goto failed; } /* * Try to get into frame sync for the first transfer to minimize * interlace artifacts in the captured picture. * it would be nice to use VL_TRANSFER_MODE_AUTOTRIGGER here so * we'd stay in frame sync but it seems to do nothing but make * videod hang with a galileo. */ #ifdef notdef VLTransferDescriptor xfer; xfer.mode = VL_TRANSFER_MODE_CONTINUOUS; xfer.trigger = VLFrameVerticalRetraceMask; xfer.delay = 0; xfer.count = 1; if (vlBeginTransfer(vlServer_, vlPath_, 1, &xfer) < 0) #endif if (vlBeginTransfer(vlServer_, vlPath_, 0, NULL) < 0) { vlPerror("vic: begin transfer"); goto failed; } #ifdef notdef /* * it would be nice to wait on frame available events from * videod rather than busy-waiting in next_frame() but the VL * interface doeson't expose the fd so you can't select on it. */ vlSelectEvents(vlServer_, vlPath_, VLNoEventsMask); #endif setsize(xsize, ysize); return; failed: shutdown_vl(); status_ = -1; } VLGrabber::VLGrabber(vlDevice& device) : device_(device), port_(VL_ANY) { frame_ = 0; framebase_ = 0; current_decimate_ = -1; current_fps_ = -1; current_port_ = -1; transferBuf_ = 0; Grabber::fps(2); decimate_ = 2; vlServer_ = 0; transferBuf_ = 0; vlPath_ = 0; } VLGrabber::~VLGrabber() { shutdown_vl(); } VLCIFGrabber::VLCIFGrabber(vlDevice& device) : VLGrabber(device) { } void VLCIFGrabber::setsize(int w, int h) { set_size_cif(w, h); } /* 411 */ inline void VLCIFGrabber::saveblk(const u_char* in, u_char* yp, u_char* up, u_char* vp, int stride, int is) { int cs = stride >> 1; for (int i = 8; --i >= 0; ) { register u_int y0, y1, u, v; u = in[0] << 24 | in[8] << 16 | in[16] << 8 | in[24]; v = in[2] << 24 | in[10] << 16 | in[18] << 8 | in[26]; y0 = in[1] << 24 | in[5] << 16 | in[9] << 8 | in[13]; y1 = in[17] << 24 | in[21] << 16 | in[25] << 8 | in[29]; ((u_int*)yp)[0] = y0; ((u_int*)yp)[1] = y1; ((u_int*)up)[0] = u; ((u_int*)vp)[0] = v; u = in[32+0] << 24 | in[32+8] << 16 | in[32+16] << 8 | in[32+24]; v = in[32+2] << 24 | in[32+10] << 16 | in[32+18] << 8 | in[32+26]; y0 = in[32+1] << 24 | in[32+5] << 16 | in[32+9] << 8 | in[32+13]; y1 = in[32+17] << 24 | in[32+21] << 16 | in[32+25] << 8 | in[32+29]; ((u_int*)yp)[2] = y0; ((u_int*)yp)[3] = y1; ((u_int*)up)[1] = u; ((u_int*)vp)[1] = v; in += is; yp += stride; up += cs; vp += cs; /* do the 2nd (y only instead of yuv) line */ y0 = in[1] << 24 | in[5] << 16 | in[9] << 8 | in[13]; y1 = in[17] << 24 | in[21] << 16 | in[25] << 8 | in[29]; ((u_int*)yp)[0] = y0; ((u_int*)yp)[1] = y1; y0 = in[32+1] << 24 | in[32+5] << 16 | in[32+9] << 8 | in[32+13]; y1 = in[32+17] << 24 | in[32+21] << 16 | in[32+25] << 8 | in[32+29]; ((u_int*)yp)[2] = y0; ((u_int*)yp)[3] = y1; in += is; yp += stride; } } void VLCIFGrabber::saveblks(const u_char* in) { int is = 4 * inw_; const u_int8_t* crv = crvec_; u_int8_t* lum = frame_; u_int8_t* chm = frame_ + framesize_; u_int off = framesize_ >> 2; crv += vstart_ * blkw_ + hstart_; lum += vstart_ * outw_ * 16 + hstart_ * 16; chm += vstart_ * (outw_ >> 1) * 8 + hstart_ * 8; int skip = hstart_ + (blkw_ - hstop_); for (int y = vstart_; y < vstop_; ++y) { const u_char* nin = in; for (int x = hstart_; x < hstop_; ++x) { int s = *crv++; if ((s & CR_SEND) != 0) saveblk(in, lum, chm, chm + off, outw_, is); in += 64; lum += 16; chm += 8; } crv += skip; lum += 15 * outw_ + skip * 16; chm += 7 * (outw_ >> 1) + skip * 8; in = nin + 16 * is; } } VL411Grabber::VL411Grabber(vlDevice& device) : VLCIFGrabber(device) { } void VL411Grabber::setsize(int w, int h) { set_size_411(w, h); } --------------27744461415E-- From rem-conf Thu Jun 05 04:54:20 1997 From rem-conf-request@tmpmail.es.net Thu Jun 05 04:54:19 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZazh-0003Kp-00; Thu, 5 Jun 1997 04:46:17 -0700 From: Isidor Kouvelas X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3670 To: Referenzzentrum fuer multimediale Teledienste cc: Ian McComb , rem-conf@tmpmail.es.net Subject: Re: Losing fps when rat + vic run together In-reply-to: Your message of "Thu, 05 Jun 1997 09:09:53 +0200." Date: Thu, 05 Jun 1997 12:45:56 +0100 Message-ID: <13005.865511156@cs.ucl.ac.uk> Sender: I.Kouvelas@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Christoph Fleck writes: >I have used rat3.0.22 and the Win95-System-Monitor say >that 70% of CPU is used. I have used rat on some >diffrent PCs (P5/90 P5/166 4/100) but there was >no Diffrence. Always 70% CPU. >So I belive that rat (Version 3.0.22 and 3.0.20) waste >with your CPU. About the other Progs. i dont know. A new binary (3.0.23) is now available for windows95 which should fix this problem. It is available from: ftp://cs.ucl.ac.uk/mice/rat/current/rat-3.0.23-win32.zip Please let me know of any problems you have. Isidor From rem-conf Thu Jun 05 10:43:29 1997 From rem-conf-request@tmpmail.es.net Thu Jun 05 10:43:28 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZgNX-0004nt-00; Thu, 5 Jun 1997 10:31:15 -0700 Message-Id: <199706051736.OAA04612@bicudo.remav.telebrasilia.gov.br> X-Mailer: Microsoft Outlook Express 4.71.0544.0 From: "Ildeu R. Borges J=?iso-8859-1?Q?=FA?=nior" To: Subject: Mrouted. Date: Wed, 5 Jun 1996 14:33:05 -0300 X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0544.0 X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list I'm triyng to use the Mrouted 3.8 with Solaris 2.5, but when I try to execute it with the -d parameter I see the following message: kernel (v0.25)/mrouted (v3.6) version mismatch Can some one help me ? ________________________________________________________________________ \\\\\\\\//////// ////////\\\\\\\\ Telebrasilia Unidade de Negocio - Telecomunicacoes Avancadas Ildeu R. Borges Junior tel: +55-61-323-2411 fax: +55-61-322-2992 From rem-conf Thu Jun 05 10:53:55 1997 From rem-conf-request@tmpmail.es.net Thu Jun 05 10:53:53 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZgcI-00053K-00; Thu, 5 Jun 1997 10:46:30 -0700 Message-ID: <503A2A3C2932CF118D8800805FD44E18039BD6D5@RED-68-MSG.dns.microsoft.com> From: Eric Fleischman To: rem-conf@es.net Subject: RTSP session length bug Date: Thu, 5 Jun 1997 10:46:05 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.30) X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list There is a bug in RTSP in that a session identifier is defined as being one or more octets long (see below) and is encouraged to be a very large random value in the Security section (section 15). I would therefore interpret this as encouraging a 4 or 8 octet session id length. However, Section 9.11 (which deals with embedded binary data) states that a session identier should be solely one byte long. No mention is made as to how to map between session ids of multiple bytes to session ids of one byte. However, I think that such mapping would be problematic: one should consistently use the same session-identifier value to refer to the same session. Therefore, I suggest that Section 9.11 be ammended to state that a one byte length value (giving the length of the session ID) preceeds the session identifier in the encapsulation approach: $ session-ID-length session-ID binary-data-length binary-data. -------------------------------- Session ID length: Section 11.26 of RTSP states that the session identifier has the same syntax as the conference identifier. Section 3.3 states that the syntax of the conference identifier is 1*OCTET. RFC 2068 section 2.1 (whose syntax is used by RTSP) states that the meaning of the Augmented BNF description of 1*element is "one or more instances" of element. Therefore, the session identifier must be one or more octets long (e.g., a 4 or an 8 byte long session identifier is legal). From rem-conf Thu Jun 05 11:08:55 1997 From rem-conf-request@tmpmail.es.net Thu Jun 05 11:08:54 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZgw9-0005W5-00; Thu, 5 Jun 1997 11:07:01 -0700 Date: Thu, 5 Jun 97 14:01:10 -0400 From: James Dryfoos X-Sender: dryfoos@deneb.llan To: "Ildeu R. Borges J=?iso-8859-1?Q?=FA?=nior" Cc: rem-conf@tmpmail.es.net Subject: Re: Mrouted. In-Reply-To: <199706051736.OAA04612@bicudo.remav.telebrasilia.gov.br> Message-Id: <9706051401.AA21072@LL.MIT.EDU> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list On Wed, 5 Jun 1996, Ildeu R. Borges J[iso-8859-1] =FAnior wrote: > Date: Wed, 5 Jun 1996 14:33:05 -0300 > From: "Ildeu R. Borges J[iso-8859-1] =FAnior" > To: rem-conf@tmpmail.es.net > Subject: Mrouted. >=20 > I'm triyng to use the Mrouted 3.8 with Solaris 2.5, but when I try to > execute it with the -d parameter I see the following message: >=20 > kernel (v0.25)/mrouted (v3.6) version mismatch >=20 > Can some one help me ? > ________________________________________________________________________ >=20 > \\\\\\\\//////// > ////////\\\\\\\\ > Telebrasilia > Unidade de Negocio - Telecomunicacoes Avancadas >=20 > Ildeu R. Borges Junior =20 > tel: +55-61-323-2411 > fax: +55-61-322-2992 See the following: From=20Sangeeta.Mukherjee@Eng.Sun.COM Thu Jun 5 14:00:39 1997 Date: Wed, 14 Feb 1996 14:27:21 -0800 From: Sangeeta Mukherjee To: mbone@isi.edu, hamby@aris.jpl.nasa.gov, joe@acomp.usf.edu, Yutaka.Matsumoto@Japan.Sun.COM, Sangeeta.Mukherjee@Eng.Sun.COM Cc: jfwang@vislab.epa.gov, jcallaha@willamette.edu, onabe@Japan.Sun.COM, dryfoos@ll.mit.edu Subject: IP Multicast 3.5/3.8 available for Solaris 2.5 Multicast version 3.5 is available for Solaris 2.5 You can get the necessary files and instructions via ftp from:=20 playground.sun.com:/pub/multicast The two relevant files are: README_mc35+.2.5 and Solaris_mc35+.2.5.tar.Z The README file gives installation instructions and other information =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D James Dryfoos (JD243) | mailto:dryfoos@ll.mit.edu MIT Lincoln Laboratory, Group 48 | 244 Wood Street, MailStop: B-120 | (617) 981-2008 - office Lexington, MA 02173-9108, Earth | (617) 981-0782 - fax =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From rem-conf Thu Jun 05 11:50:03 1997 From rem-conf-request@tmpmail.es.net Thu Jun 05 11:50:02 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZhYS-0006CJ-00; Thu, 5 Jun 1997 11:46:36 -0700 Sender: hgs@dnrc.bell-labs.com Message-ID: <3397085C.2848@cs.columbia.edu> Date: Thu, 05 Jun 1997 14:41:32 -0400 From: "Henning Schulzrinne (BL)" Organization: Columbia University X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m) MIME-Version: 1.0 To: Eric Fleischman CC: rem-conf@es.net, confctrl@isi.edu Subject: Re: RTSP session length bug References: <503A2A3C2932CF118D8800805FD44E18039BD6D5@RED-68-MSG.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list A choice needs to be made if in-band TCP data (a hopefully rare occurrence) should be allowed only when one TCP connection represents one RTSP session at a time. If so, the in-band data session ID is unnecessary; if not, it needs to be of variable and unbounded length (basically, a string) and be the same as the session identifier carried as "Session:". Comments? Eric Fleischman wrote: > > There is a bug in RTSP in that a session identifier is defined as being > one or more octets long (see below) and is encouraged to be a very large > random value in the Security section (section 15). I would therefore > interpret this as encouraging a 4 or 8 octet session id length. > > However, Section 9.11 (which deals with embedded binary data) states > that a session identier should be solely one byte long. No mention is > made as to how to map between session ids of multiple bytes to session > ids of one byte. However, I think that such mapping would be > problematic: one should consistently use the same session-identifier > value to refer to the same session. > > Therefore, I suggest that Section 9.11 be ammended to state that a one > byte length value (giving the length of the session ID) preceeds the > session identifier in the encapsulation approach: $ session-ID-length > session-ID binary-data-length binary-data. > > -------------------------------- > Session ID length: Section 11.26 of RTSP states that the session > identifier has the same syntax as the conference identifier. Section 3.3 > states that the syntax of the conference identifier is 1*OCTET. RFC 2068 > section 2.1 (whose syntax is used by RTSP) states that the meaning of > the Augmented BNF description of 1*element is "one or more instances" of > element. Therefore, the session identifier must be one or more octets > long (e.g., a 4 or an 8 byte long session identifier is legal). -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 908 949 8344 (at Bell Labs) Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs From rem-conf Thu Jun 05 11:50:16 1997 From rem-conf-request@tmpmail.es.net Thu Jun 05 11:50:15 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZhbW-0006JV-00; Thu, 5 Jun 1997 11:49:46 -0700 Date: Thu, 5 Jun 1997 11:28:18 -0700 () From: Stephen Casner To: Scott Petrack , "Michael F. Speer" , Steven McCanne cc: rem-conf@es.net Subject: Re: Overriding a defined static payload type In-Reply-To: Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Scott, > I would like to suggest a small change to the RTP text to allow the dynamic > payload types to override the static types if there is a need in a single > session for more than the number of dynamic payload types available. Given that I have been promoting wider use of dynamic payload types, I guess I should be in favor of this proposal. Somehow it makes me a little uncomfortable, though. I guess the question is whether there should be any provision for allowing some endpoints to participate with, say, manually entered partial information. If we evolve to the point where in many cases only dynamic payload types are used, then the manual mode won't work anyway. > 1. With layered encodings becoming more and more important, and bandwidth > becoming more and more avaiable, I can see a situation where a single > session might need a lot of different payload types. Already a group of 8 > or 10 participants using different layered codecs might need too many > dynamic payload types. That's a possibility, but I wonder if it is realistic that many different layered codecs will be used in the same session. Also, the question of needing many payload types for a layered codec is not one that I recall discussing before. The Speer/McCanne draft (draft-speer-avt-layered-video-01.txt) on extensions to RTP for layered encodings does not mention payload types, unless I overlooked it. The RTP code would be cognizant of the grouping of sequential pairs of ports (and sequential multicast addresses for the multicast case), so perhaps it was expected that the same payload type could be used for all of the layers. Michael or Steve, do you have a comment on that? > 2. There are undoubtedly many coders in the basic A/V profile which will > not be very popular not too many years from now. It would be a shame to > have to write a new profile just because these by-then-obsolete coders take > up room in the payload type space. True, although if in practice the 32 codes preallocated for dynamic payload formats are sufficient for any given session, then there would be no need to make use of the obsolete static codes. The real impetus for writing a new profile would come from needing to make more static assignments once the space was full. If everything is dynamic at that point, then there's no problem. > 3. Such a change will not break anything that exists now. At least not until one of the static codes was overridden. > Of course it may be that if this problem ever actually appears, consenting > applications will just override the static types anyway. That's probably true. Adopting that behavior may cause interoperation to fail given some implementations that perform a validity check on the dynamic payload type range. Presumably that's the point of proposing the change. I'd like to hear opinions from other AVT working group participants (which means any interested parties). -- Steve From rem-conf Thu Jun 05 17:55:11 1997 From rem-conf-request@tmpmail.es.net Thu Jun 05 17:55:10 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZnF2-0001Gu-00; Thu, 5 Jun 1997 17:50:56 -0700 Message-Id: <3.0.32.19970605175018.00ef3610@mail.prognet.com> X-Sender: robla@mail.prognet.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 05 Jun 1997 17:50:30 -0700 To: "Henning Schulzrinne (BL)" , Eric Fleischman From: Rob Lanphier Subject: Re: RTSP session length bug Cc: rem-conf@es.net, confctrl@isi.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list At 02:41 PM 6/5/97 -0400, Henning Schulzrinne (BL) wrote: >A choice needs to be made if in-band TCP data (a hopefully rare >occurrence) should be allowed only when one TCP connection represents >one RTSP session at a time. If so, the in-band data session ID is >unnecessary; if not, it needs to be of variable and unbounded length >(basically, a string) and be the same as the session identifier carried >as "Session:". Comments? Since the rtp/tcp wasn't fully speced out, I can see why there's confusion here. I was presuming the interaction would go something like the following: C->S SETUP rtsp://foo.com/bar.file RTSP/1.0 2 Transport: rtp/tcp;mplex=0 S->C RTSP/1.0 200 2 OK Date: 05 Jun 1997 18:57:18 GMT Transport: rtp/tcp;mplex=0 Session: 12345 C->S PLAY rtsp://foo.com/bar.file RTSP/1.0 3 Session: 12345 S->C RTSP/1.0 200 3 OK Session: 12345 Date: 05 Jun 1997 18:59:15 GMT S->C $\000{2 byte length}{"length" bytes data, w/RTP header} S->C $\000{2 byte length}{"length" bytes data, w/RTP header} S->C $\000{2 byte length}{"length" bytes data, w/RTP header} S->C $\000{2 byte length}{"length" bytes data, w/RTP header} C->S SETUP rtsp://foo.com/blech.file RTSP/1.0 4 Transport: rtp/tcp;mplex=1 S->C RTSP/1.0 200 4 OK Date: 05 Jun 1997 18:57:18 GMT Transport: rtp/tcp;mplex=1 Session: 67890 C->S PLAY rtsp://foo.com/blech.file RTSP/1.0 5 Session: 67890 S->C RTSP/1.0 200 5 OK Session: 67890 Date: 05 Jun 1997 18:59:15 GMT S->C $\001{2 byte length}{"length" bytes data, w/RTP header} S->C $\000{2 byte length}{"length" bytes data, w/RTP header} S->C $\001{2 byte length}{"length" bytes data, w/RTP header} S->C $\000{2 byte length}{"length" bytes data, w/RTP header} S->C $\001{2 byte length}{"length" bytes data, w/RTP header} ..... This would allow 256 streams over a single TCP connection. Not perfect, but in the case where you have more than 256 sessions, one could argue that a second TCP connection is no great hardship. There are Huffman-esque tricks that I think we can do, but I would prefer not to bother specing them (and hence adding one more complience hoop) and instead negotiate those via PEP if folks find it necessary (hey, a great use for PEP!) Rob --- Rob Lanphier Voice: (206)674-2322 Fax: (206)674-2699 Program Manager-Protocols Email: robla@prognet.com Progressive Networks-Home of RealAudio Web: http://www.real.com For more information on firewalls: http://www.real.com/firewall.html For more information on RTSP: http://www.real.com/prognet/rt From rem-conf Thu Jun 05 22:36:20 1997 From rem-conf-request@tmpmail.es.net Thu Jun 05 22:36:19 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZrbh-00026N-00; Thu, 5 Jun 1997 22:30:37 -0700 Message-ID: <3397A19E.EC019F96@nwork.chungbuk.ac.kr> Date: Fri, 06 Jun 1997 14:35:27 +0900 From: "Jongil, Park" Reply-To: jipark@nwork.chungbuk.ac.kr Organization: Computer Engineering of CBU X-Mailer: Mozilla 4.0b5 [en] (Win95; I) MIME-Version: 1.0 To: "Henning Schulzrinne (BL)" CC: Eric Fleischman , rem-conf@es.net, confctrl@isi.edu Subject: [Q] About vic? X-Priority: 3 (Normal) References: <503A2A3C2932CF118D8800805FD44E18039BD6D5@RED-68-MSG.dns.microsoft.com> <3397085C.2848@cs.columbia.edu> Content-Type: text/plain; charset=iso-8859-1 X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Hi, everyone. I'm studying about RTP and control of multimedia application control. Has Vic jiiter tolerance in some degree? and other prgoram? sorry poor english...puhehe ---------------------------------------------------------- Computer Engineering, Chungbuk National University, Korea Network Laboratory Jong-il, Park (Webmaster) http://nwork.chungbuk.ac.kr/~jipark http://dce3.chungbuk.ac.kr/bbs/ http://cbubbs.chungbuk.ac.kr/ (Administrator) ---------------------------------------------------------- From rem-conf Fri Jun 06 04:38:36 1997 From rem-conf-request@tmpmail.es.net Fri Jun 06 04:38:36 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZxHx-0003H6-00; Fri, 6 Jun 1997 04:34:37 -0700 Message-Id: <199706061139.IAA07370@bicudo.remav.telebrasilia.gov.br> X-Mailer: Microsoft Outlook Express 4.71.0544.0 From: "Ildeu R. Borges J=?iso-8859-1?Q?=FA?=nior" To: Cc: Subject: Mrouted again. Date: Fri, 6 Jun 1997 08:36:48 -0300 X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0544.0 X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Sorry, but I didn't understand, I have to use the patch "Solaris_mc35+_2_5-p atch" ? I already used the Mrouted 3.5 and I got the same message (kernel version ......mrouted version). ________________________________________________________________________ \\\\\\\\//////// ////////\\\\\\\\ Telebrasilia Unidade de Negocio - Telecomunicacoes Avancadas Ildeu R. Borges Junior tel: +55-61-323-2411 fax: +55-61-322-2992 From rem-conf Fri Jun 06 04:50:23 1997 From rem-conf-request@tmpmail.es.net Fri Jun 06 04:50:23 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZxVo-0003bm-00; Fri, 6 Jun 1997 04:48:56 -0700 Date: Fri, 6 Jun 1997 12:41:20 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: "Ildeu R. Borges J=?iso-8859-1?Q?=FA?=nior" cc: dryfoos@ll.mit.edu, rem-conf@tmpmail.es.net Subject: Re: Mrouted again. In-Reply-To: <199706061139.IAA07370@bicudo.remav.telebrasilia.gov.br> 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=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list On Fri, 6 Jun 1997, Ildeu R. Borges J=FAnior wrote: > Sorry, but I didn't understand, I have to use the patch "Solaris_mc35+_2_= 5-p > atch" ? I already used the Mrouted 3.5 and I got the same message (kernel > version ......mrouted version). That patch is not mrouted 3.5. That patch is a kernel patch (version 3.5) which provides support for mrouted 3.8. You must apply this patch for mrouted 3.8 to work.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D 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/mic= e/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D From rem-conf Fri Jun 06 05:40:37 1997 From rem-conf-request@tmpmail.es.net Fri Jun 06 05:40:36 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wZyGy-00042M-00; Fri, 6 Jun 1997 05:37:40 -0700 To: Stephen Casner cc: Scott Petrack , "Michael F. Speer" , Steven McCanne , rem-conf@es.net Subject: Re: Overriding a defined static payload type In-reply-to: Your message of "Thu, 05 Jun 1997 11:28:18 PDT." Date: Fri, 06 Jun 1997 13:34:10 +0100 Message-ID: <1247.865600450@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list --> Stephen Casner writes: >> I would like to suggest a small change to the RTP text to allow the dynamic >> payload types to override the static types if there is a need in a single >> session for more than the number of dynamic payload types available. > >Given that I have been promoting wider use of dynamic payload types, I >guess I should be in favor of this proposal. Somehow it makes me a >little uncomfortable, though. I guess the question is whether there >should be any provision for allowing some endpoints to participate >with, say, manually entered partial information. If we evolve to the >point where in many cases only dynamic payload types are used, then >the manual mode won't work anyway. Presumably the change would be to allow, for example, the video range of static payload types to be used for audio, hence expanding the valid audio range. This is, at least, an easily detectable change and a tool writer can choose to treat this as an additional dynamic range if necessary. The profile could be rewritten to specify three distinct payload type ranges: audio, video and dynamic. Tools which only understand audio could treat the video range as dynamic, and vice versa. The option of overriding, say, an existing static audio payload type, with another audio payload, seems to be inviting trouble. Colin From rem-conf Sun Jun 08 13:50:36 1997 From rem-conf-request@tmpmail.es.net Sun Jun 08 13:50:35 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0waofD-0002rO-00; Sun, 8 Jun 1997 13:34:11 -0700 Date: Sun, 8 Jun 1997 16:36:43 -0400 (EDT) From: Ramana M Lavu X-Sender: rlavu@bacon To: rem-conf@tmpmail.es.net Subject: encrypted mbone session Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Hi! I want to create an private mbone session using encryption can you please tell me where I can find documentation for using encryption with sdr, or any other kind of help is greatly appreciated. Thanks in advance, Ramana. From rem-conf Mon Jun 09 11:36:31 1997 From rem-conf-request@tmpmail.es.net Mon Jun 09 11:36:30 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wb99M-0005eG-00; Mon, 9 Jun 1997 11:26:40 -0700 Date: Mon, 9 Jun 1997 11:25:33 -0700 (PDT) From: "Michael F. Speer" Reply-To: "Michael F. Speer" Subject: Re: Overriding a defined static payload type To: Stephen Casner Cc: Scott Petrack , "Michael F. Speer" , Steven McCanne , rem-conf@es.net In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Comments enclosed: > Scott, > > > I would like to suggest a small change to the RTP text to allow the dynamic > > payload types to override the static types if there is a need in a single > > session for more than the number of dynamic payload types available. > > Given that I have been promoting wider use of dynamic payload types, I > guess I should be in favor of this proposal. Somehow it makes me a > little uncomfortable, though. I guess the question is whether there > should be any provision for allowing some endpoints to participate > with, say, manually entered partial information. If we evolve to the > point where in many cases only dynamic payload types are used, then > the manual mode won't work anyway. > > > 1. With layered encodings becoming more and more important, and bandwidth > > becoming more and more avaiable, I can see a situation where a single > > session might need a lot of different payload types. Already a group of 8 > > or 10 participants using different layered codecs might need too many > > dynamic payload types. > > That's a possibility, but I wonder if it is realistic that many > different layered codecs will be used in the same session. > > Also, the question of needing many payload types for a layered codec > is not one that I recall discussing before. The Speer/McCanne draft > (draft-speer-avt-layered-video-01.txt) on extensions to RTP for > layered encodings does not mention payload types, unless I overlooked > it. The RTP code would be cognizant of the grouping of sequential > pairs of ports (and sequential multicast addresses for the multicast > case), so perhaps it was expected that the same payload type could be > used for all of the layers. Michael or Steve, do you have a comment > on that? Origiallny when written, we assumed the same payload type for all layers. This is certainly true for the layered coders that I know of. I think the issue of dyanmic payload types is orthogonal to the layered codecs. Do layered coders really generate different types of video or audio from that of the base layer? Michael From rem-conf Mon Jun 09 16:58:48 1997 From rem-conf-request@tmpmail.es.net Mon Jun 09 16:58:47 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wbE5y-00003S-00; Mon, 9 Jun 1997 16:43:30 -0700 Date: Tue, 10 Jun 1997 09:43:24 +1000 (EST) From: Mr Kieran Power To: Ramana M Lavu cc: rem-conf@tmpmail.es.net Subject: Re: encrypted mbone session In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list On Sun, 8 Jun 1997, Ramana M Lavu wrote: > Hi! > I want to create an private mbone session using > encryption can you please tell me where I can find documentation > for using encryption with sdr, or any other kind of help > is greatly appreciated. > > Thanks in advance, > Ramana. > > > Hi, Try looking at http://nic.merit.edu/~mbone/index/titles.html. Under the section Audio Utils there is an application called SpeakFreely. It supports DES and IDEA and can be used with PGP. Have Fun, Kieran Power. From rem-conf Tue Jun 10 03:18:16 1997 From rem-conf-request@tmpmail.es.net Tue Jun 10 03:18:16 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wbNuO-0001WP-00; Tue, 10 Jun 1997 03:12:12 -0700 X-Mailer: exmh version 1.6.6 3/24/96 To: rem-conf@es.net Subject: MERCI Seminar tomorrow, Wednesday 11 June Date: Tue, 10 Jun 1997 11:08:53 +0100 Message-ID: <694.865937333@cs.ucl.ac.uk> From: Roy Bennett X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list The Multimedia European Research Conferencing Integration (MERCI) project, funded by the Commisssion of the European Community, will tomorrow multicast another seminar in an occasional series on subjects in Multimedia, Communications, Networks, Distributed Systems and CSCW. The session is advertised in sdr as "MERCI Seminar". The slides must be accessed via the web at the URL specified in sdr and you are encouraged to provide us with feedback on your experience in participating in the seminar via the form provided. Those completing the form will be provided with a summary of the results. Time: 15-16:00 UTC From: University College London (UCL) Chair: Professor Peter Kirstein Speaker: Danny Cohen, Myrinet Title: "Myrinet, an EXISTING gigabit/sec network" Abstract: Myrinet is a Gigabit-per-second network that has been shipping since 1994. Myrinet is used for applications such as LAN (e.g., at USC/ISI), for inter-cabinet and intra-cabinet SAN, and also as anintra-card SAN. Today's Myrinet components include full duplex, 1.28+1.28 Gigabit/s links, cut-through switches, and programmable PCI and SBus interfaces. Like Ethernet, Myrinet is defined at the Data Link level, and has multiple Physical implementations: SAN (System-Area Network) cables for in-cabinet applications, LAN cables for moderate distances, and fiber for longer distances. Due to its excellent performance/cost, Myrinet is already used in 120 sites in 14 countries, particularly for "clusters" of workstations and PCs. The talk will cover: Myrinet technology, components, and software Applications (NOWs, COWs, and SANs) Benchmarks Technology roadmap Lessons for other Gigabit networks -- bottlenecks and market ----------------------------------------------------------------------- Roy Bennett, Project Manager, MERCI http://www-mice.cs.ucl.ac.uk/merci/ Computer Science Phone: +44 171 380 7934 University College London Fax: +44 171 387 1397 Gower Street, LONDON WC1E 6BT Email: rbennett@cs.ucl.ac.uk ----------- http://www-dept.cs.ucl.ac.uk/staff/R.Bennett -------------- From rem-conf Tue Jun 10 08:12:10 1997 From rem-conf-request@tmpmail.es.net Tue Jun 10 08:12:09 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wbSVs-0002MK-00; Tue, 10 Jun 1997 08:07:12 -0700 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Mr Kieran Power cc: Ramana M Lavu , rem-conf@tmpmail.es.net Subject: Re: encrypted mbone session In-reply-to: Your message of "Tue, 10 Jun 1997 09:43:24 +1000." Date: Tue, 10 Jun 1997 11:05:59 -0400 Message-ID: <20034.865955159@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list >> I want to create an private mbone session using >> encryption can you please tell me where I can find documentation >> for using encryption with sdr, or any other kind of help >> is greatly appreciated. Sdr 2.3a1 supports DES encryption. You must communicate a plain-text key (at least 10 characters), key-name (human readable) and key-id (numeric, 0 .. 2^32-1) to the people in your private group. Do this out of band using any channel you feel is secure. Enter this information into sdr on the Security preferences panel. Then you can make encrypted announcements. There was a bug in the DES code that broke sdr encryption on little-endian machines in sdr 2.3a1, but I'm no longer working on sdr encryption code as I'm now subject to US export restrictions. Someone else will have to fix this from the original source on ftp://cs.ucl.ac.uk/mice/sdr/. I believe someone at UCL is going to do further work on SAP security. Note also that the key-id field is being removed from the SAP protocol specification, so future versions of session directories will not be compatible with sdr 2.3a1 when using encryption. Mark From rem-conf Wed Jun 11 09:03:57 1997 From rem-conf-request@tmpmail.es.net Wed Jun 11 09:03:56 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wbppS-00077z-00; Wed, 11 Jun 1997 09:00:58 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Wed, 11 Jun 1997 09:00:40 -0700 (PDT) Message-Id: <199706111600.JAA12957@hille.msri.org> To: rem-conf@es.net From: mmadrid Reply-to: mmadrid@psc.edu Subject: PSC Computational Neuroscience Workshop X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: PSC Computational Neuroscience Workshop Date: Jun 13, 1997 Time: 09:00 EST 7 hours Contact: mmadrid@psc.edu URL: http://www.psc.edu/biomed/workshops/wk-97/neuro/neural.html Description: Agenda and lecture notes can be found at the URL above. Participants in this workshop will learn to use PGENESIS, a parallel version of the GENESIS simulator, and PNEURON (under development), a parallel version of the NEURON simulator. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Wed Jun 11 09:03:58 1997 From rem-conf-request@tmpmail.es.net Wed Jun 11 09:03:58 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wbpdM-00072O-00; Wed, 11 Jun 1997 08:48:28 -0700 From: chris.whittenburg@wcom.com (Chris Whittenburg) Message-Id: <9706111547.AA03922@phantom.wcom.com> Subject: VIC q-factor To: rem-conf@es.net Date: Wed, 11 Jun 1997 10:47:18 -0500 (CDT) Cc: kevin@cc.gatech.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text UUEncode: TRUE X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list I've found it's easy to start vic from a command line and specify bandwidth, fps, capture device, transmitOnStartup, but I can't find how to set the q-factor this way. My goal is low frame rate but very high resolution images viewable from Precept's IP/TV viewer. The only thing I've found close to this is to use vic set h.261 and a very low Q-factor. thanks for any pointers, chris -- Chris Whittenburg Data Network Mechanic (918) 590-5845 Worldcom Inc. chris.whittenburg@wcom.com From rem-conf Wed Jun 11 09:03:58 1997 From rem-conf-request@tmpmail.es.net Wed Jun 11 09:03:58 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wbppb-000781-00; Wed, 11 Jun 1997 09:01:07 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Wed, 11 Jun 1997 09:00:11 -0700 (PDT) Message-Id: <199706111600.JAA12930@hille.msri.org> To: rem-conf@es.net From: mmadrid Reply-to: mmadrid@psc.edu Subject: PSC Computational Neuroscience Workshop X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: PSC Computational Neuroscience Workshop Date: Jun 12, 1997 Time: 09:00 EST 7 hours Contact: mmadrid@psc.edu URL: http://www.psc.edu/biomed/workshops/wk-97/neuro/neural.html Description: Agenda and lecture notes can be found at the URL above. Participants in this workshop will learn to use PGENESIS, a parallel version of the GENESIS simulator, and PNEURON (under development), a parallel version of the NEURON simulator. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Wed Jun 11 09:07:21 1997 From rem-conf-request@tmpmail.es.net Wed Jun 11 09:07:21 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wbpt9-0007ZO-00; Wed, 11 Jun 1997 09:04:47 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Wed, 11 Jun 1997 09:01:53 -0700 (PDT) Message-Id: <199706111601.JAA12984@hille.msri.org> To: rem-conf@es.net From: mmadrid Reply-to: mmadrid@psc.edu Subject: PSC Computational Neuroscience Workshop X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: PSC Computational Neuroscience Workshop Date: Jun 14, 1997 Time: 09:00 EST 1.5 hours Contact: mmadrid@psc.edu URL: http://www.psc.edu/biomed/workshops/wk-97/neuro/neural.html Description: Agenda and lecture notes can be found at the URL above. Participants in this workshop will learn to use PGENESIS, a parallel version of the GENESIS simulator, and PNEURON (under development), a parallel version of the NEURON simulator. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Wed Jun 11 09:40:19 1997 From rem-conf-request@tmpmail.es.net Wed Jun 11 09:40:18 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wbqOH-00016E-00; Wed, 11 Jun 1997 09:36:57 -0700 Message-ID: <01BC764A.243A76C0@christian.icast.com> From: Christian McMillan To: 'Chris Whittenburg' , "rem-conf@es.net" Cc: "kevin@cc.gatech.edu" Subject: RE: VIC q-factor Date: Wed, 11 Jun 1997 09:30:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Chris, Kevin, and others. Our ICAST server allows for "on the fly" settings of quality, fps and = bandwidth all integrated in one UI. If you are interested please let me = know and I can provide a 30 day demo software trial. ICAST Corporation's servers (encoders really) run on Win 95, NT 4.0 and = Unix Free BSD. (Solaris 2.x soon).=20 The Channel viewer and guide (SD) run on Win 95, NT 4.0 and also as = plug-in's for Navigator and Explorer 3.0. Regards, Christian McMillan =3D_____________________________________________=3D Christian McMillan 408.874.0714 Direct=09 ICAST Corporation 408.874.0710 Fax Sales Manager 1-888-945-1637 Pager E-Page Christian@metrocall.com =3D_____________________________________________=3D -----Original Message----- From: Chris Whittenburg [SMTP:chris.whittenburg@wcom.com] Sent: Wednesday, June 11, 1997 8:47 AM To: rem-conf@es.net Cc: kevin@cc.gatech.edu Subject: VIC q-factor I've found it's easy to start vic from a command line and specify bandwidth, fps, capture device, transmitOnStartup, but I can't find how to set the q-factor this way. My goal is low frame rate but very high resolution images viewable from Precept's IP/TV viewer. The only thing I've found close to this is to use vic set h.261 and a very low Q-factor. thanks for any pointers, chris --=20 Chris Whittenburg Data Network Mechanic (918) 590-5845 Worldcom Inc. chris.whittenburg@wcom.com From rem-conf Wed Jun 11 10:17:05 1997 From rem-conf-request@tmpmail.es.net Wed Jun 11 10:17:04 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wbqut-0001iU-00; Wed, 11 Jun 1997 10:10:39 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <01BC764A.243A76C0@christian.icast.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Jun 1997 10:10:36 -0700 To: Christian McMillan From: Steve Deering Subject: RE: VIC q-factor Cc: "rem-conf@es.net" X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list At 9:30 AM -0700 6/11/97, Christian McMillan wrote: > ICAST Corporation's servers (encoders really) run on Win 95, NT 4.0 and > Unix Free BSD. (Solaris 2.x soon). > > The Channel viewer and guide (SD) run on Win 95, NT 4.0 and also as > plug-in's for Navigator and Explorer 3.0. Sigh. Let me know when you have a MacOS version. Steve From rem-conf Wed Jun 11 19:47:54 1997 From rem-conf-request@tmpmail.es.net Wed Jun 11 19:47:53 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wbzrE-0004H2-00; Wed, 11 Jun 1997 19:43:28 -0700 Message-Id: <199706120243.TAA27651@tikal.synopsys.com> To: baylisa@baylisa.org, rem-conf@es.net, sage-members@usenix.org Cc: bigmac@baylisa.org Subject: BayLISA June 19: Robert Harker on Sendmail Date: Wed, 11 Jun 1997 19:43:23 -0700 From: Bryan McDonald X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list The BayLISA group meets monthly to discuss topics of interest to systems and network administrators. The meetings are free and open to the public. Please feel free to redistribute this meeting announcement. BayLISA holds monthly meetings on the third Thursday of each month at 7:30 PM PST. We meet at Cisco Building J in San Jose, on Tasman Drive near First street. See www.baylisa.org for more information. The meetings are also broadcast via MBONE. Schedule -------- June 19, 1997: Robert Harker, Sendmail [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 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. =============================================================================== Bryan McDonald bigmac@baylisa.org President president@baylisa.org BayLISA http://www.baylisa.org =============================================================================== From rem-conf Thu Jun 12 07:53:38 1997 From rem-conf-request@tmpmail.es.net Thu Jun 12 07:53:38 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wcB8c-0006TI-00; Thu, 12 Jun 1997 07:46:10 -0700 To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: rem-conf@es.net From: The IESG Subject: Protocol Action: RTP Payload Format for H.263 Video Streams to Proposed Standard Date: Thu, 12 Jun 1997 10:26:40 -0400 Sender: scoya@ietf.org Message-ID: <9706121026.aa11053@ietf.org> X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list The IESG has approvedRTP Payload Format for H.263 Video Streams for publication as a Proposed Standard.This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Allyn Romanow and Scott Bradner. Technical Summary This document descibes a scheme for packetizing an H.263 video stream for transport using the Real-Time Transport Protocol (RTP, RFC1889). H.263 video coding for low bitrate communication is defined by ITU-T Recommendation H.263 and is widely used for video teleconferencing. It builds on H.261, offering more options and a compressed encoding which is more supportive of lower bitrates. Three modes are defined for the H.263 payload header. An RTP packet can use one of the three modes for H.263 video streams depending on the desired network packet size and H.263 encoding options employed. The shortest H.263 payload header (mode A) supports fragmentation at Group of Block (GOB) boundaries. The long H.263 payload headers (mode Ba dn C) support fragmentation at Macroblock (MB) boundaries. Working Group Summary There was no debate or controversy in the working group. Protocol Quality This document was reviewed for the IESG by Allyn Romanow. From rem-conf Fri Jun 13 07:26:48 1997 From rem-conf-request@tmpmail.es.net Fri Jun 13 07:26:47 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wcX0c-00052r-00; Fri, 13 Jun 1997 07:07:22 -0700 Message-ID: <19970613110704.33509@mscs.cs.dal.ca> Date: Fri, 13 Jun 1997 11:07:04 -0300 From: Trent MacDougall To: rem-conf@es.net Subject: 11th Annual Canadian Internet Conference Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: 11th Annual Canadian Internet Conference: Net '97 Date: June 22-25, 1997 Time: 0900 AST Daily (starting June 23) Contact: Trent.MacDougall@Dal.Ca URL: http://net97.dal.ca Description: Canada's foremost Internet experts will meet at Dalhousie on June 22-25 for Net '97, the 11th Annual Canadian Internet Conference. Net'97 brings together the pioneers of the Internet, and touches on the latest issues in large-scale networking. Topics include telemedicine, community net software, the most recent news in videoconferncing and Internet "multicasting" as well as results from the latest Internet user survey. Other Net '97 highlights include a presentation by Nick Ketchum on CRTC's perspective on policy development, and an update on CA*Net II -- the beginning of a new Internet backbone specifically for research and education. From rem-conf Fri Jun 13 10:28:02 1997 From rem-conf-request@tmpmail.es.net Fri Jun 13 10:28:01 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wcZof-000110-00; Fri, 13 Jun 1997 10:07:13 -0700 From: Richard Gallup Date: Fri, 13 Jun 1997 10:07:08 -0700 Message-Id: <199706131707.KAA01586@solomon> To: mbone@isi.edu, rem-conf@es.net Subject: Mbone broadcast of President Clinton's USCD Commencement Address X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list UC San Diego and the San Diego Supercomputer Center to Present Live Broadcast of President Clinton's Commencement Address. On Saturday, June 14, 1997, President William Jefferson Clinton will deliver the keynote address at the commencement ceremonies of the University of California, San Diego (UCSD). SDSC is providing the enabling technology to broadcast President Clinton's address on the Multicast Backbone (Mbone). According to the White House Press Secretary Michael McCurry, President Clinton will discuss the diversity of the American people, and will talk specifically about how to reconcile antagonisms between races and bring people together in one America to use diversity to make progress in the 21st century. The Mbone broadcast will air from 9 a.m. to noon Pacific Standard Time, and President Clinton's speech is slated to begin at about 10 a.m. The commencement address will also be available live on the Internet at http://www.ucsd.edu/commencement . More than 6,000 people will be able to simultaneously view the Webcast. Viewers may choose to access audio only or audio and video. The Webcast will use a new platform called RealVideo which has been created by Progressive Networks. This platform provides live video for any user who has a connection to the Internet and a 28.8 modem or higher. Users will simply need to download free software from RealVideo. A link is provided from the UC San Diego commencement Web site. The SDR session will be announced as: "President Clinton's UCSD Commencement Address" Richard Gallup -- From rem-conf Fri Jun 13 12:10:51 1997 From rem-conf-request@tmpmail.es.net Fri Jun 13 12:10:50 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wcbcE-0001jT-00; Fri, 13 Jun 1997 12:02:30 -0700 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: rem-conf@es.net Subject: broken ICAST session announcements Date: Fri, 13 Jun 1997 15:01:21 -0400 Message-ID: <2303.866228481@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list It doesn't seem like anyone at ICAST reads their mail, so I'm sending to the list instead.... Just in case anyone is wondering why they can't join various sessions, or the calendar in sdr has stopped working; the reason is that ICAST seem to be making session announcements with a broken session directory tool. Four obvious things show up: - a media format of "RTP/AVP H261" which should read "RTP/AVP 31" (the payload type of H.261 is 31). Also "RTP/AVP PCM" which should read "RTP/AVP 0". Thus valid session directories shouldn't let you join these sessions. - a repeat interval of 0 seconds! This is what is causing sdr's calendar to break. I've a fix in sdr 2.4 but don't want to release this yet until I've finished the SIP code. - a protocol of RTP/SRM. There is no RTP profile for SRM so this is invalid. - an attribute of "datarate". SDP has a perfectly usable bandwidth field, so no new attribute is required for this. Perhaps someone at ICAST could fix their directory, or simply stop using it until it is fixed. Thanks, Mark From rem-conf Fri Jun 13 13:50:02 1997 From rem-conf-request@tmpmail.es.net Fri Jun 13 13:50:01 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wcdF6-0002RG-00; Fri, 13 Jun 1997 13:46:44 -0700 Message-ID: <33A1B196.5340@icast.com> Date: Fri, 13 Jun 1997 13:46:14 -0700 From: Vinay Kumar Reply-To: vinay@icast.com Organization: ICAST Corp X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: Mark Handley CC: rem-conf@es.net Subject: Re: broken ICAST session announcements References: <2303.866228481@buttle.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list mark, thank you for being impatient. all the stuff you mentioned have been fixed (almost)..:) we are testing the fix's. thank you for your earlier msg's, some of us are reading'em...:) --- vinay Mark Handley wrote: > > It doesn't seem like anyone at ICAST reads their mail, so I'm sending > to the list instead.... > > Just in case anyone is wondering why they can't join various sessions, > or the calendar in sdr has stopped working; the reason is that ICAST > seem to be making session announcements with a broken session > directory tool. > > Four obvious things show up: > > - a media format of "RTP/AVP H261" which should read "RTP/AVP 31" (the > payload type of H.261 is 31). Also "RTP/AVP PCM" which should read > "RTP/AVP 0". Thus valid session directories shouldn't let you join > these sessions. > > - a repeat interval of 0 seconds! This is what is causing sdr's > calendar to break. I've a fix in sdr 2.4 but don't want to release > this yet until I've finished the SIP code. > > - a protocol of RTP/SRM. There is no RTP profile for SRM so this is > invalid. > > - an attribute of "datarate". SDP has a perfectly usable bandwidth > field, so no new attribute is required for this. > > Perhaps someone at ICAST could fix their directory, or simply stop > using it until it is fixed. > > Thanks, > Mark From rem-conf Fri Jun 13 18:17:18 1997 From rem-conf-request@tmpmail.es.net Fri Jun 13 18:17:17 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wch2U-00057s-00; Fri, 13 Jun 1997 17:49:58 -0700 Message-Id: <199706140049.RAA11465@tikal.synopsys.com> To: baylisa@baylisa.org, rem-conf@es.net, sage-members@usenix.org Cc: bigmac@baylisa.org Subject: BayLISA June 19: Robert Harker on LDAP and Sendmail 8.8 Date: Fri, 13 Jun 1997 17:49:49 -0700 From: Bryan McDonald X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list The BayLISA group meets monthly to discuss topics of interest to systems and network administrators. The meetings are free and open to the public. Please feel free to redistribute this meeting announcement. BayLISA holds monthly meetings on the third Thursday of each month at 7:30 PM PST. We meet at Cisco Building J in San Jose, on Tasman Drive near First street. See www.baylisa.org for more information. The meetings are also broadcast via MBONE. Schedule ======== June 19, 1997: Robert Harker, LDAP and Sendmail 8.8 "Lightwight Directory Access Protocol (LDAP) is currently one of the buzz words used by the Internet software providers. It is touted as the solution to all of you information directory needs. The problem is that not very many people know about it much less how an organization can use it, much less how to impliment and deploy it. This talk is an introduction to what LDAP is and how to use it. It is based on my studies of using LDAP with sendmail 8.8." [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 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. =============================================================================== Bryan McDonald bigmac@baylisa.org President president@baylisa.org BayLISA http://www.baylisa.org =============================================================================== From rem-conf Mon Jun 16 08:21:19 1997 From rem-conf-request@tmpmail.es.net Mon Jun 16 08:21:18 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wddEu-0005Er-00; Mon, 16 Jun 1997 07:58:40 -0700 Date: Mon, 16 Jun 1997 10:58:31 -0400 (EDT) From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199706161458.KAA29963@grinch.cc.gatech.edu> To: kevin@cc.gatech.edu Subject: Sessions on the IMJ X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list This e-mail is going out to a number of lists, and I cringe to do it, but it is relevant to all... I'm ready to announce that many of the sessions from the Memphis IETF that were MBoned are now available on the IMJ (http://imj.gatech.edu) for on-demand playback... AVT, MMUSIC, IDMR, MBONED, TCPSAT, and the multicast WWW BOF. You can schedule programs via the WWW page and start the MBone sessions via SDR (or the WWW page with a simple plug-in). Other encoded sessions are forthcoming, but the turmoil of graduation, moving, etc might delay others. (If anyone has a real interest in seeing something else in the very near future, please send me e-mail.) In the future, I hope to have the sessions available much more rapidly. Updates: and just for those interested... the imj has changed machines, but imj.gatech.edu moved with it. Also MBone routing on campus has been slightly upgraded (Solaris plus 3.9) so hopefully we'll be able to avoid the memory leaks of 4.1.3. Also, the volume problem on all the new stuff should be fixed (thanks to an audio mixer), and there is a new section for oldies-but-goodies. Finally, and as usual, I've included the originial IMJ e-mail announcement for those who haven't seen it. Any suggestions for improvement are welcome. -Kevin Announcing the Interactive Multimedia Jukebox At one point on the MBone list there was a discussion of what on-demand servers exist or are being developed. Well, I'd like to announce our version called the Interactive Multimedia Jukebox (IMJ). The IMJ web page is a request and scheduling interface for the playout of content over the MBone. CONTENT IS ENCODED SO THAT IT CAN BE RECEIVED WITH THE LATEST VERSIONS OF VIC AND VAT (ANY PLATFORM). The IMJ page is located at http://imj.gatech.edu. Information about the IMJ including general info, a postscript version of a paper about the IMJ, how-to-use information, and how it was implemented can be found at http://www.cc.gatech.edu/computing/Telecomm/IMJ/. Some quick additional information about the IMJ is included below: IMJ Audio/Video ----------------- The IMJ uses the WWW to submit requests which are then scheduled for playout on the MBone. Right now we are offering three channels: Channels 1 and 2 are being broadcast at a TTL of 127. Channel 3 is for internal testing and has a a TTL of 15. Each channel provides DVI-2 audio and 128 Kbps H.261 video. The encoding was done using Henning Schulzrinne's rtpplay and rtpdump. Scheduling ---------- Program scheduling uses a set of criteria to decide on which channel to schedule a program. The current set of criteria are listed just below the interactive schedule. We are exploring lots of different options. Content ------- We have been working on the jukebox paradigm with Turner Broadcasting, and as a result of their interest they have agreed to let us broadcast content on the MBone. I am particularly excited about this aspect because of their help and interest in investigating new applications on the Internet. The plan is to add a new set of content about every two weeks. When this happens, the old content will be moved to the secondary request menu for two weeks. The old-old stuff will be removed. Hopefully I'll be able to advertise on the MBone list when the new stuff is available. Development Platform -------------------- As is mentioned in the paper on the IMJ information page we are using the IMJ as a platform for a variety of research issues including providing interactivity, supporting multiple heterogeneous streams, video server organization, tracking usage, program scheduling, and pricing. Acknowledgments ---------------- In addition to Turner Broadcasting, several other groups have made the IMJ possible. The GT Broadband Telecommunications Center sponsored much of the research and some of the equipment, and GT Office of Information Technology offered technical assistance and additional equipment. Please send me any feedback or suggestions. Thanks. -Kevin Almeroth From rem-conf Tue Jun 17 07:21:14 1997 From rem-conf-request@tmpmail.es.net Tue Jun 17 07:21:13 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wdyv9-00057t-00; Tue, 17 Jun 1997 07:07:43 -0700 Date: Tue, 17 Jun 1997 14:54:31 +0100 From: annemari@mcg.gla.ac.uk (Anne Marie Fleming) Message-Id: <199706171354.OAA10019@kestrel.mcg.gla.ac.uk> To: rem-conf@es.net Subject: Vic and high frame rates X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Hi folks, Has anyone had any trouble running vic at a high frame rate? We are attempting to run Vic (v2.8) on a dedicated network between two Sun sparc 20's running solaris 2.5.1. The two machines seem to have difficulty when they are both attempting to send and receive at approx 25 - 30 fps with a loss rate of about 70-80%. When we run two separate vics on each machine - one to transmit and the other to receive, the problem evaporates and both machines can cope with sending and receiving 25 - 30 fps with little or no loss. We would prefer not to be running multiple versions of vic so if anyone has any ideas ...... thanks annemari ============================================================================= Anne Marie Fleming email: annemari@mcg.gla.ac.uk Multimedia Communications Group www url: http://www.mcg.gla.ac.uk/ University of Glasgow Tel: +44 41 330 5424 52 Hillhead Street Fax: +44 41 339 8889 Glasgow G12 8QB Telex: 777070 UNIGLA ============================================================================= From rem-conf Wed Jun 18 01:51:54 1997 From rem-conf-request@tmpmail.es.net Wed Jun 18 01:51:53 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0weGHi-0001dx-00; Wed, 18 Jun 1997 01:40:10 -0700 Message-Id: <199706180839.KAA03879@renoir.uio.no> X-Mailer: exmh version 1.6.7 5/3/96 To: rem-conf@es.net Subject: Vic and harware compression (O2) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Jun 1997 10:39:28 +0200 From: Frank J|rgen Solem X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list As far as i know, the SGI O2 has some hardware for h.261 compression, but I don't think the normal vic distribution uses this hardware compression. Are there anyone who has used the h.261 hardware compression with vic on an O2? I assume this might decrease bandwith and increase quality, especially if the O2 has motion detection. Are there any (other) workstations where vic might use h.261 hardware compression, either natively or with some optional hardware? -- Frank Solem University of Oslo Ph: +47 2285 2478 Center for Information Technology Services From rem-conf Wed Jun 18 03:51:43 1997 From rem-conf-request@tmpmail.es.net Wed Jun 18 03:51:43 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0weIGy-0002Al-00; Wed, 18 Jun 1997 03:47:32 -0700 X-Mailer: exmh version 2.0gamma 1/27/96 From: Piers O'Hanlon Organisation: MultiMedia Support and Comms Centre, University College London,Uk Phone: +44 171 636 8333 ext 3056 (Hang on in there...) X-url: http://www.avc.ucl.ac.uk To: Frank J|rgen Solem cc: rem-conf@es.net, P.OHanlon@cs.ucl.ac.uk Subject: Re: Vic and harware compression (O2) In-reply-to: Your message of "Wed, 18 Jun 1997 10:39:28 +0200." <199706180839.KAA03879@renoir.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Jun 1997 11:35:13 +0100 Message-ID: <1750.866630113@cs.ucl.ac.uk> Sender: P.OHanlon@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list > > As far as i know, the SGI O2 has some hardware for h.261 compression, but > I don't think the normal vic distribution uses this hardware compression. > Are there anyone who has used the h.261 hardware compression with vic on > an O2? I assume this might decrease bandwith and increase quality, > especially if the O2 has motion detection. > As I understand vic - It only uses Intra-H261 (ie only Intra coded frames with conditional(only send those above a threshold of change) replenishment) which means there would be no advantage gained from motion detection or prediction done in hardware, though the accelerated DCT would make a difference - Though I guess it depends on how configurable the hardware is and whether it allows much control of the encoding process so one could get it to generate H261 usable by vic. Although one could probably use H261 straight from hardware it is usually H261 suitable for low loss ISDN type links, which when sent over [lossy] packet nets would grow nasty holes due to its dependence on prediction and motion detection. see ftp://ftp.ee.lbl.gov/papers/vic-mm95.ps.Z > Are there any (other) workstations where vic might use h.261 hardware > compression, either natively or with some optional hardware? > There was talk of using the Bitfield (http://www.bitfield.fi) EISA hardware codec in vic but I don't think it was done - possibly due to lack of access to useful H261. Anyway it would be interesting to hear about hardware used. Piers O'Hanlon ______________ MultiMedia Support and Comms Centre University College London. From rem-conf Wed Jun 18 06:57:13 1997 From rem-conf-request@tmpmail.es.net Wed Jun 18 06:57:12 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0weL6O-0002pF-00; Wed, 18 Jun 1997 06:48:48 -0700 Message-Id: <199706181348.PAA17871@ganymede.cdt.luth.se> X-Mailer: exmh version 1.6.7 5/3/96 To: Piers O'Hanlon Cc: rem-conf@es.net Subject: Re: Vic and harware compression (O2) In-reply-to: Your message of "Wed, 18 Jun 1997 11:35:13 BST." <1750.866630113@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 18 Jun 1997 15:48:30 +0200 From: Hakan Lennestal Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list In message <1750.866630113@cs.ucl.ac.uk>, "Piers O'Hanlon" writes: > means there would be no advantage gained from motion detection or predi= ction=20 > done in hardware, though the accelerated DCT would make a difference - = Though There used to be an option (maybe it's still there ?) in vic to use the jpeg DCT in the SunVideo hardware when encoding h.261. /H=E5kan From rem-conf Wed Jun 18 07:47:11 1997 From rem-conf-request@tmpmail.es.net Wed Jun 18 07:47:11 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0weLw6-0003Fs-00; Wed, 18 Jun 1997 07:42:14 -0700 X-Mailer: exmh version 2.0gamma 1/27/96 From: Piers O'Hanlon Organisation: MultiMedia Support and Comms Centre, University College London,Uk Phone: +44 171 636 8333 ext 3056 (Hang on in there...) X-url: http://www.avc.ucl.ac.uk To: Hakan Lennestal cc: Piers O'Hanlon , rem-conf@es.net Subject: Re: Vic and harware compression (O2) In-reply-to: Your message of "Wed, 18 Jun 1997 15:48:30 +0200." <199706181348.PAA17871@ganymede.cdt.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jun 1997 15:41:57 +0100 Message-ID: <2831.866644917@cs.ucl.ac.uk> Sender: P.OHanlon@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list > = > > means there would be no advantage gained from motion detection or pre= diction = > > done in hardware, though the accelerated DCT would make a difference = - Though > = > There used to be an option (maybe it's still there ?) in vic to use > the jpeg DCT in the SunVideo hardware when encoding h.261. > = It is there. It seemed to come from Steve McCanne and Elan Amir's vgw pro= gram: http://www.cs.berkeley.edu/~elan/vgw/README.html Although I have encountered the odd bit of wierdness with it - The receiv= ed = stream doesn't seem to be decoded if the receiving vic is started after t= he = transmitter has been started (with 'Use JPEG for H261' on sunvideo). Piers O'Hanlon ______________ MultiMedia Support and Comms Centre University College London. From rem-conf Wed Jun 18 08:46:15 1997 From rem-conf-request@tmpmail.es.net Wed Jun 18 08:46:15 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0weMtR-0003tW-00; Wed, 18 Jun 1997 08:43:33 -0700 From: Biersack Ernst Date: Wed, 18 Jun 1997 17:45:52 +0200 (MET DST) Message-Id: <199706181545.RAA16733@lilie.eurecom.fr> To: rem-conf@es.net Subject: SIGCOMM 97 final program Cc: erbi@alpes.eurecom.fr X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list The annual ACM SIGCOMM 97 Conference on Applications, Technologies, Architectures and Protocols for Computer Communication will take place from September 14 to 18 in Cannes, France. There are many good reasons why you should attend: An outstanding technical program comprising - Tutorials: Sunday September 14 and Monday September 15 - Conference: Tuesday September 16 to Thursday (morning) September 18 A superb social program with: - Wine and cheese tasting: Monday September 15, 18:00 to 21:00 - Pool session: Tuesday September 16, 19:00 to 22:00 around the Hotel Majestic pool Workshops right after the conference: - Internet Simulations with the NS simulator: Thursday (afternoon) September 18 - Reliable Multicast Meeting: Friday and Saturday September 19-20 Student travel Grants (application deadline July 1st !!) Register now!! (Early registration rates until August 1st) For more information and the registrations forms see: http://www.inria.fr/rodeo/sigcomm97/ Ernst Biersack (SIGCOMM 97 publicity chair) From rem-conf Wed Jun 18 20:44:27 1997 From rem-conf-request@tmpmail.es.net Wed Jun 18 20:44:27 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0weY2H-0006oe-00; Wed, 18 Jun 1997 20:37:25 -0700 From: Alan Batie Message-Id: <199706190337.UAA28307@agora.rdrop.com> Subject: Re: BayLISA June 19: Robert Harker on Sendmail To: bigmac@synopsys.com (Bryan McDonald) Date: Wed, 18 Jun 1997 20:37:05 -0700 (PDT) Cc: baylisa@baylisa.org, rem-conf@es.net, sage-members@usenix.org, bigmac@baylisa.org In-Reply-To: <199706120243.TAA27651@tikal.synopsys.com> from "Bryan McDonald" at Jun 11, 97 07:43:23 pm X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list > June 19, 1997: Robert Harker, Sendmail I would have tuned in, but the channel information was nowhere to be found... -- Alan Batie ______ It's not my fault! It's some guy batie@agora.rdrop.com \ / named "General Protection"! +1 503 452-0960 \ / --Ratbert PGP FP: DE 3C 29 17 C0 49 \/ 7A 27 40 A5 3C 37 4A DA 52 B9 It is my policy to avoid purchase of any products from companies which use unrequested email advertisements or telephone solicitation. From rem-conf Wed Jun 18 21:04:36 1997 From rem-conf-request@tmpmail.es.net Wed Jun 18 21:04:36 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0weYRc-0007At-00; Wed, 18 Jun 1997 21:03:36 -0700 Message-Id: <199706190403.VAA22063@tikal.synopsys.com> To: baylisa@baylisa.org, rem-conf@es.net, sage-members@usenix.org Cc: bigmac@baylisa.org Subject: BayLISA June 19: Robert Harker on LDAP and Sendmail 8.8 Date: Wed, 18 Jun 1997 21:03:33 -0700 From: Bryan McDonald X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list ===Last reminder about tomorrow nights talk.=== The BayLISA group meets monthly to discuss topics of interest to systems and network administrators. The meetings are free and open to the public. Please feel free to redistribute this meeting announcement. BayLISA holds monthly meetings on the third Thursday of each month at 7:30 PM PST. We meet at Cisco Building J in San Jose, on Tasman Drive near First street. See www.baylisa.org for more information. The meetings are also broadcast via MBONE. Schedule ======== June 19, 1997: Robert Harker, LDAP and Sendmail 8.8 "Lightwight Directory Access Protocol (LDAP) is currently one of the buzz words used by the Internet software providers. It is touted as the solution to all of you information directory needs. The problem is that not very many people know about it much less how an organization can use it, much less how to impliment and deploy it. This talk is an introduction to what LDAP is and how to use it. It is based on my studies of using LDAP with sendmail 8.8." [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 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. =============================================================================== Bryan McDonald bigmac@baylisa.org President president@baylisa.org BayLISA http://www.baylisa.org =============================================================================== From rem-conf Thu Jun 19 00:39:14 1997 From rem-conf-request@tmpmail.es.net Thu Jun 19 00:39:13 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0webjG-0000gR-00; Thu, 19 Jun 1997 00:34:02 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Thu, 19 Jun 1997 00:33:20 -0700 (PDT) Message-Id: <199706190733.AAA16548@hille.msri.org> To: rem-conf@es.net From: jyluke Reply-to: jyluke@ew.mimos.my Subject: Keynote and Plenary for INET 97 1st Session X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Keynote and Plenary for INET 97 1st Session Date: Jun 25, 1997 Time: 08:30 GMT+8 2 hours Contact: jyluke@ew.mimos.my URL: http://www.isoc.org/inet97/ Description: ISOC's INET 97 will be held in Kuala Lumpur this year. There will be three prenary sessions to be held from 25/6 to 27/6. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Jun 19 00:39:16 1997 From rem-conf-request@tmpmail.es.net Thu Jun 19 00:39:16 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0weblG-0000gs-00; Thu, 19 Jun 1997 00:36:06 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Thu, 19 Jun 1997 00:35:34 -0700 (PDT) Message-Id: <199706190735.AAA16579@hille.msri.org> To: rem-conf@es.net From: jyluke Reply-to: jyluke@ew.mimos.my Subject: Keynote and Plenary for INET 97 - 2nd Day X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Keynote and Plenary for INET 97 - 2nd Day Date: Jun 26, 1997 Time: 08:30 GMT+8 2 hours Contact: jyluke@ew.mimos.my URL: http://www.isoc.org/inet97/ Description: This is the 2nd day of INET 97 held in Kuala Lumpur. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Jun 19 00:41:49 1997 From rem-conf-request@tmpmail.es.net Thu Jun 19 00:41:48 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0webo5-0000hK-00; Thu, 19 Jun 1997 00:39:01 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Thu, 19 Jun 1997 00:38:18 -0700 (PDT) Message-Id: <199706190738.AAA16610@hille.msri.org> To: rem-conf@es.net From: jyluke Reply-to: jyluke@ew.mimos.my Subject: Closing Plenary for INET 97 X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Closing Plenary for INET 97 Date: Jun 27, 1997 Time: 10:00 GMT8 2 hours Contact: jyluke@ew.mimos.my URL: http://www.isoc.org/inet97/ Description: The last session for the INET 97 conference. The actual starting time will be 10:30am (GMT8) and will end at 12:30pm (GMT8). mbone broadcast schedule http://www.msri.org/mbone From rem-conf Fri Jun 20 11:43:45 1997 From rem-conf-request@tmpmail.es.net Fri Jun 20 11:43:44 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wf8NG-0007Os-00; Fri, 20 Jun 1997 11:25:30 -0700 Date: Fri, 20 Jun 1997 11:22:21 -0700 (PDT) Message-Id: <199706201822.LAA06253@geoplex.geoplex.com> From: "Edin (Dino) Hodzic" To: rem-conf@es.net Subject: tunnels/mrouted Reply-to: dino@geoplex.com X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Hello, is it true that in the current implementation of mrouted (3.8.2) and corresponding multicast support (i.e. 3.5+ in Solaris), tunnels are not treated the same way as interfaces? In particular, is it the case that the multicast router on one side of a tunnel will forward all the multicast data through the tunnel even though there may be no multicast group participants, for (most of) the multicast data forwarded, on the other side of the tunnel? I am lead to these questions by my understanding that kernel does not keep the list of multicast groups associated with a tunnel, while it does for a physint. I also believe I understand correctly that the DVMRP V3 will treat physints and tunnels identically, implying that multicast data would not be forwarded on a tunnel unless there are participants on the other side. Is this the case? Thanks. -Dino -- _ , EDIN "DINO" HODZIC, AT&T phone: 408-576-1370 address: 2665 N. 1ST St. #300, San Jose, CA 95134 mailto:dino@geoplex.com, mailto:ehodzic@scu.edu http://pcsel10.scu.edu/~ehodzic From rem-conf Fri Jun 20 19:57:53 1997 From rem-conf-request@tmpmail.es.net Fri Jun 20 19:57:51 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wfGGp-0001JZ-00; Fri, 20 Jun 1997 19:51:23 -0700 Message-Id: <199706210250.TAA05858@mailhost.Ipsilon.COM> To: dino@geoplex.com cc: rem-conf@es.net Subject: Re: tunnels/mrouted In-reply-to: Your message of "Fri, 20 Jun 1997 11:22:21 PDT." <199706201822.LAA06253@geoplex.geoplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Jun 1997 19:50:36 -0700 From: "Danny J. Mitzel" X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list >> is it true that in the current implementation of mrouted (3.8.2) and >> corresponding multicast support (i.e. 3.5+ in Solaris), tunnels are >> not treated the same way as interfaces? In particular, is it the case >> that the multicast router on one side of a tunnel will forward all the >> multicast data through the tunnel even though there may be no >> multicast group participants, for (most of) the multicast data >> forwarded, on the other side of the tunnel? I am lead to these >> questions by my understanding that kernel does not keep the list of >> multicast groups associated with a tunnel, while it does for a physint. dvmrp forwards packets on an interface if any of the following conditions hold for the packet : 1) there are downstream dependent dvmrp routers for the source 2) there are local group members tunnels do not allow local group membership, thus condition (2) is always FALSE. so forwarding over a tunnel is completely dependent on condition (1), and prune/graft works exactly as on any physical interface. >> I also believe I understand correctly that the DVMRP V3 will treat >> physints and tunnels identically, implying that multicast data would >> not be forwarded on a tunnel unless there are participants on the >> other side. Is this the case? DVMRPv3 states that IGMP packets (DVMRP probe/route/prune/graft) should be sent ip-in-ip encapsulated, just like forwarded data packets. in the current model the IGMP packets are unicasted directly to the tunnel remote endpoint. I believe this is primarily a hack to allow firewall configurations to only open one hole between the tunnel endpoints, rather than two. anyways, it again has no effect on dvmrp prune/graft behaviour. cheers, danny From rem-conf Sun Jun 22 14:13:29 1997 From rem-conf-request@tmpmail.es.net Sun Jun 22 14:13:28 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wftc0-00070G-00; Sun, 22 Jun 1997 13:51:52 -0700 To: dino@geoplex.com cc: rem-conf@es.net Subject: Re: tunnels/mrouted In-reply-to: Your message of "Fri, 20 Jun 97 11:22:21 PDT." <199706201822.LAA06253@geoplex.geoplex.com> Date: Sun, 22 Jun 1997 13:51:31 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <97Jun22.135136pdt.177512@crevenia.parc.xerox.com> X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list "Edin (Dino) Hodzic" wrote: >In particular, is it the case >that the multicast router on one side of a tunnel will forward all the >multicast data through the tunnel even though there may be no >multicast group participants, for (most of) the multicast data >forwarded, on the other side of the tunnel? It is true that mrouted does not keep a list of multicast group memberships for tunnels, but that is because it's not possible to have a group membership on a tunnel (in the current implementation of tunnels). However, a neighbor relationship with a peer over a tunnel acts just like a neighbor relationship with a peer over a normal interface; packets are only forwarded over the tunnel if the peer has built up the forwarding tree for the packet's source with a poison-reverse route update, and if the peer has not pruned the group. On a normal interface, packets can *also* be forwarded if there is a group member on that interface, but that is completely independent of the presence of a neighbor who has built the forwarding tree; mrouted will forward a packet if either condition is true. >I also believe I understand correctly that the DVMRP V3 will treat >physints and tunnels identically, implying that multicast data would >not be forwarded on a tunnel unless there are participants on the >other side. Is this the case? DVMRP has always treated neighbors on physical interfaces and tunnels identically. DVMRPv3 does not change anything in this respect. Bill From rem-conf Sun Jun 22 22:13:40 1997 From rem-conf-request@tmpmail.es.net Sun Jun 22 22:13:39 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wg1Mx-0000Vl-00; Sun, 22 Jun 1997 22:08:51 -0700 Message-Id: <199706230406.OAA03644@sarang.kyungsung.ac.kr> To: "rem-conf@es.net" Subject: Reservation Session Date: Mon, 23 Jun 97 14:04:57 -0500 From: Jong Kuk Lee X-Mailer: E-Mail Connection v2.5.03 X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list Hello. I'm a member of Mbone-kr (Korean mbone group). & a chief of Dept Mbone-kr Broadcasting I reserve a session. Session Name is "KR-Net'97 Workshop". This workshop is a Greatest workshop of Internet in Korea. This Workshop is broadcasted from 30.June to 2.July, ( During 3 Days ). I will announce exactly this session after 3 days. See you later. From rem-conf Mon Jun 23 04:29:30 1997 From rem-conf-request@tmpmail.es.net Mon Jun 23 04:29:30 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wg7D3-0001bh-00; Mon, 23 Jun 1997 04:23:01 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Mon, 23 Jun 1997 04:21:31 -0700 (PDT) Message-Id: <199706231121.EAA18954@hille.msri.org> To: rem-conf@es.net From: sixvideo Reply-to: sixvideo@si.ehu.es Subject: XVI Summer School/IX European Courses (The University of the Basque Country - Spain) X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: XVI Summer School/IX European Courses (The University of the Basque Country - Spain) Date: Jul 01, 1997 Time: 09:00 GMT+2 5 hours Contact: sixvideo@si.ehu.es URL: http://www.sc.ehu.es/scrwwwsu/c1.htm Description: Course:"NATURAL LANGUAGE PROCESSING: A PRINCIPLES AND PARAMETERS PERSPECTIVE" Description: This course presents a general overview of language processing based on the Chomskyan model of principles and parameters. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Mon Jun 23 04:29:41 1997 From rem-conf-request@tmpmail.es.net Mon Jun 23 04:29:41 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wg7Gu-0001cS-00; Mon, 23 Jun 1997 04:27:00 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Mon, 23 Jun 1997 04:25:26 -0700 (PDT) Message-Id: <199706231125.EAA18981@hille.msri.org> To: rem-conf@es.net From: sixvideo Reply-to: sixvideo@si.ehu.es Subject: XVI Summer School/IX European Courses (The University of the Basque Country - Spain) X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: XVI Summer School/IX European Courses (The University of the Basque Country - Spain) Date: Jul 02, 1997 Time: 09:00 GMT+2 5 hours Contact: sixvideo@si.ehu.es URL: http://www.sc.ehu.es/scrwwwsu/c1.htm Description: Course:"NATURAL LANGUAGE PROCESSING: A PRINCIPLES AND PARAMETERS PERSPECTIVE" Description: This course presents a general overview of language processing based on the Chomskyan model of principles and parameters. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Mon Jun 23 04:29:44 1997 From rem-conf-request@tmpmail.es.net Mon Jun 23 04:29:43 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wg7H3-0001cW-00; Mon, 23 Jun 1997 04:27:09 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Mon, 23 Jun 1997 04:26:08 -0700 (PDT) Message-Id: <199706231126.EAA19008@hille.msri.org> To: rem-conf@es.net From: sixvideo Reply-to: sixvideo@si.ehu.es Subject: XVI Summer School/IX European Courses (The University of the Basque Country - Spain) Day 2 X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: XVI Summer School/IX European Courses (The University of the Basque Country - Spain) Day 2 Date: Jul 02, 1997 Time: 09:00 GMT+2 5 hours Contact: sixvideo@si.ehu.es URL: http://www.sc.ehu.es/scrwwwsu/c1.htm Description: Course:"NATURAL LANGUAGE PROCESSING: A PRINCIPLES AND PARAMETERS PERSPECTIVE" Description: This course presents a general overview of language processing based on the Chomskyan model of principles and parameters. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Mon Jun 23 04:30:21 1997 From rem-conf-request@tmpmail.es.net Mon Jun 23 04:30:21 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wg7Hd-0001ci-00; Mon, 23 Jun 1997 04:27:45 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Mon, 23 Jun 1997 04:26:49 -0700 (PDT) Message-Id: <199706231126.EAA19035@hille.msri.org> To: rem-conf@es.net From: sixvideo Reply-to: sixvideo@si.ehu.es Subject: XVI Summer School/IX European Courses (The University of the Basque Country - Spain) Day 3 X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: XVI Summer School/IX European Courses (The University of the Basque Country - Spain) Day 3 Date: Jul 03, 1997 Time: 09:00 GMT+2 5 hours Contact: sixvideo@si.ehu.es URL: http://www.sc.ehu.es/scrwwwsu/c1.htm Description: Course:"NATURAL LANGUAGE PROCESSING: A PRINCIPLES AND PARAMETERS PERSPECTIVE" Description: This course presents a general overview of language processing based on the Chomskyan model of principles and parameters. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Mon Jun 23 04:31:36 1997 From rem-conf-request@tmpmail.es.net Mon Jun 23 04:31:36 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wg7Iq-0001d1-00; Mon, 23 Jun 1997 04:29:00 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Mon, 23 Jun 1997 04:28:10 -0700 (PDT) Message-Id: <199706231128.EAA19062@hille.msri.org> To: rem-conf@es.net From: sixvideo Reply-to: sixvideo@si.ehu.es Subject: XVI Summer School/IX European Courses (The University of the Basque Country - Spain) Day 4 X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: XVI Summer School/IX European Courses (The University of the Basque Country - Spain) Day 4 Date: Jul 04, 1997 Time: 09:00 GMT+2 5 hours Contact: sixvideo@si.ehu.es URL: http://www.sc.ehu.es/scrwwwsu/c1.htm Description: Course:"NATURAL LANGUAGE PROCESSING: A PRINCIPLES AND PARAMETERS PERSPECTIVE" Description: This course presents a general overview of language processing based on the Chomskyan model of principles and parameters. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Mon Jun 23 06:44:44 1997 From rem-conf-request@tmpmail.es.net Mon Jun 23 06:44:43 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wg9NY-0003sX-00; Mon, 23 Jun 1997 06:42:00 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Mon, 23 Jun 1997 06:41:19 -0700 (PDT) Message-Id: <199706231341.GAA19282@hille.msri.org> To: rem-conf@es.net From: multicast Reply-to: multicast@dxcoms.cern.ch Subject: CERN LHCC X-Mailing-List: X-Loop: rem-conf@tmpmail.es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: CERN LHCC Date: Jul 10, 1997 Time: 09:00 GMT+1 4 hours Contact: multicast@noc.cern.ch URL: http://sunmed2.cern.ch:8888/LHCC_10_07_97.html Description: LARGE HADRON COLLIDER COMMITTEE Session on Thursday 10 July from the CERN Auditorium mbone broadcast schedule http://www.msri.org/mbone From rem-conf Mon Jun 23 14:53:26 1997 From rem-conf-request@es.net Mon Jun 23 14:53:26 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wgGrA-00067H-00; Mon, 23 Jun 1997 14:41:04 -0700 Date: Mon, 23 Jun 1997 14:37:27 -0700 (PDT) Message-Id: <199706232137.OAA08563@geoplex.geoplex.com> From: "Edin (Dino) Hodzic" To: mitzel@Ipsilon.COM CC: rem-conf@es.net, arlied@microsoft.com, fenner@parc.xerox.com Subject: Re: tunnels/mrouted Reply-to: dino@geoplex.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thank you all for your replies. My understanding is incorrect, I guess, because of the documentation I have been using. I have primarily focused on the "TCP/IP Illustrated Volume 2" book by Steven's, which describes an earlier version of multicast, and only gives hints about the version 3.3. The earlier version had multicast routing table which included source address only and not the group address, and didn't support pruning. The latest version of multicast support multicast routing cache, which is substantially different (I guess because of pruning support). I have downloaded 4.4BSD-Lite which implements pre-3.3 multicast, so it does not help me much. Here are my new questions: - is there any documentation which describes the 3.5 multicast. In particular, the interface between the kernel and mrouted, and the division of responsibilities between the kernel and mrouted w.r.t. multicast routing and forwarding? - is there free BSD code I can take a look at in order to understand multicast 3.5? - is there any documentation describing the implementation of mrouted, other than its source code? Again, thank you for replies and for your help. Sincerely, Dino -- _ , EDIN "DINO" HODZIC, AT&T phone: 408-576-1370 address: 2665 N. 1ST St. #300, San Jose, CA 95134 mailto:dino@geoplex.com, mailto:ehodzic@scu.edu http://pcsel10.scu.edu/~ehodzic From rem-conf Mon Jun 23 15:06:43 1997 From rem-conf-request@es.net Mon Jun 23 15:06:42 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wgHEi-0006Yn-00; Mon, 23 Jun 1997 15:05:24 -0700 From: sohraby@lucent.com Date: Mon, 23 Jun 97 17:46:39 EDT Original-From: kas1@hoserve.ho.lucent.com Message-Id: <9706232146.AA01747@qc54.ho.lucent.com> To: rem-conf@es.net Subject: IEEE Network Magazine: CALL FOR PAPERS X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IEEE Network Magazine Special Issue on PCS Network Management Guest editors: Yi-Bing Lin Kazem Shoraby Dept. Comp. Sci. & Info. Engr. Lucent Technologies National Chiao Tung University Bell Laboratories, Room 3K-334 Hsinchu, Taiwan, R.O.C. 101 Crawfords Corner Rd. Fax: +886-35724176 Holmdel, NJ 07733 USA liny@csie.nctu.edu.tw Email: sohraby@lucent.com Voice: 908-949-0496 Fax: 908-834-5906 Scope: Personal communications services (PCS) provide communication services anywhere, anytime, with anybody, and in any form. To implement these communications concepts, extremely sophisticated network management which integrates many diverse technologies are required. This special issue focuses on the research and development of advanced PCS network management techniques. Concise, tutorially oriented reference of the state-of-the art or original contributions related to the following topics are solicited: - Small scale mobility (inter-system handover) management - Large scale mobility (roaming) management - Security (privacy and authentication) management - Multi-system interworking - PCS database reliability - Intelligent networks for PCS - Network management for PCS data and multimedia applications - PCS transport network issues (Internet, PSTN, PSDN, ATM) - Modeling of PCS network management (measurement, analysis, and simulation) Authors are invited to submit postscript files of their papers to liny@csie.nctu.edu.tw or sohraby@lucent.com. Papers should not exceed twenty double spaced pages in length, excluding figures and diagrams. Submission deadline: October 25, 1997 Acceptance notification: February 25, 1998 Final manuscript due: April 25, 1998 From rem-conf Mon Jun 23 15:19:19 1997 From rem-conf-request@es.net Mon Jun 23 15:19:19 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wgHOx-0006sp-00; Mon, 23 Jun 1997 15:15:59 -0700 To: dino@geoplex.com cc: rem-conf@es.net, fenner@parc.xerox.com Subject: Re: tunnels/mrouted In-reply-to: Your message of "Mon, 23 Jun 97 14:37:27 PDT." <199706232137.OAA08563@geoplex.geoplex.com> Date: Mon, 23 Jun 1997 15:14:22 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <97Jun23.151437pdt.177512@crevenia.parc.xerox.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list "Edin (Dino) Hodzic" wrote: > - is there any documentation which describes the 3.5 > multicast. In particular, the interface between the kernel > and mrouted, and the division of responsibilities between the > kernel and mrouted w.r.t. multicast routing and forwarding? Not really. The division is farily straightforward, though -- the kernel forwards, mrouted makes the forwarding decision. If the kernel gets a packet for which it doesn't have a forwarding cache entry, it asks mrouted to install a forwarding cache entry for it. The kernel has no state other than the forwarding cache that mrouted installs and can't make any decisions on its own. > - is there free BSD code I can take a look at in order to > understand multicast 3.5? All of FreeBSD, NetBSD and OpenBSD have the 3.5 multicast code. They are each available from ftp.bsd.org . > - is there any documentation describing the implementation of > mrouted, other than its source code? Unfortunately, no. Bill From rem-conf Mon Jun 23 16:05:03 1997 From rem-conf-request@es.net Mon Jun 23 16:05:03 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wgI9H-0007Wa-00; Mon, 23 Jun 1997 16:03:51 -0700 Date: Mon, 23 Jun 1997 16:00:46 -0700 (PDT) Message-Id: <199706232300.QAA12080@geoplex.geoplex.com> From: "Edin (Dino) Hodzic" To: fenner@parc.xerox.com CC: rem-conf@es.net, fenner@parc.xerox.com Subject: Re: tunnels/mrouted Reply-to: dino@geoplex.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >>>>> On Mon, 23 Jun 1997 15:14:22 PDT, Bill Fenner said: Bill> "Edin (Dino) Hodzic" wrote: >> - is there any documentation which describes the 3.5 >> multicast. In particular, the interface between the kernel >> and mrouted, and the division of responsibilities between the >> kernel and mrouted w.r.t. multicast routing and forwarding? Bill> Not really. The division is farily straightforward, though -- the Bill> kernel forwards, mrouted makes the forwarding decision. If the kernel Bill> gets a packet for which it doesn't have a forwarding cache entry, it Bill> asks mrouted to install a forwarding cache entry for it. The kernel Bill> has no state other than the forwarding cache that mrouted installs and Bill> can't make any decisions on its own. >> - is there free BSD code I can take a look at in order to >> understand multicast 3.5? Bill> All of FreeBSD, NetBSD and OpenBSD have the 3.5 multicast code. Bill> They are each available from ftp.bsd.org . >> - is there any documentation describing the implementation of >> mrouted, other than its source code? Bill> Unfortunately, no. Bill> Bill Bill, thank you very much for the prompt replies. Is the DVMRP protocol, as implemented by the latest mrouted, described by an RFC or internet draft? I know about the original RFC-1075, the version one DVMRP, and draft-ietf-idmr-dvmrp-v3-04.txt, the version three of the protocol. Is the version of DVMRP which multicast 3.5/mrouted implement much different from DVMRP V3? Thanks. -Dino From rem-conf Mon Jun 23 16:15:40 1997 From rem-conf-request@es.net Mon Jun 23 16:15:39 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wgIJh-00007t-00; Mon, 23 Jun 1997 16:14:37 -0700 From: Bill Fenner To: dino@geoplex.com, fenner@parc.xerox.com Subject: Re: tunnels/mrouted Cc: rem-conf@es.net Message-Id: <97Jun23.161428pdt.177512@crevenia.parc.xerox.com> Date: Mon, 23 Jun 1997 16:14:21 PDT X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Is the version of DVMRP which multicast >3.5/mrouted implement much different from DVMRP V3? No. The DVMRP v3 document is an attempt to codify mrouted's behavior and clear up ambiguities. mrouted 3.x follows the DVMRPv3 spec pretty closely, and I'm pretty sure that mrouted 3.9-beta (ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/beta-test/) follows it exactly. Bill From rem-conf Mon Jun 23 17:21:07 1997 From rem-conf-request@es.net Mon Jun 23 17:21:07 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wgJIu-0000nl-00; Mon, 23 Jun 1997 17:17:52 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 Jun 1997 17:22:53 +0100 To: rem-conf@tmpmail.es.net From: Ursula Hawkins Subject: NASA STS-94 Space Shuttle session X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list NASA Ames Research Center is pleased to provide live coverage of NASA STS-94 Microgravity Science Laboratory-1 as a service to the MBone community. Mission STS-94 Microgravity Science Laboratory-1 is the 23rd flight of Columbia and the 85th mission flown since the start of the Space Shuttle program in April 1981 conducted by NASA. This is a reflight for the Space Shuttle Columbia and reflight of the Microgravity Science Laboratory-1. As many of you will recall the original MSL-1 mission during STS-83 was shortned. The experiments and activities associated with STS-94 are a preview for the work that will be performed on the International Space Station. Official launch date is scheduled for July 1, 1997. Duration of mission scheduled for 15days, 16hours, and 46minutes. Questions or comments: Mark Allard mallard@mail.arc.nasa.gov or Ursula Hawkins uhawkins@mail.arc.nasa.gov Ursula Hawkins Video/Audio Networks& Systems Engineering Group (VANSEG) M/S 233-10 (415)604-2443 uhawkins@mail.arc.nasa.gov From rem-conf Tue Jun 24 04:07:09 1997 From rem-conf-request@es.net Tue Jun 24 04:07:08 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wgTJC-0003EZ-00; Tue, 24 Jun 1997 03:58:50 -0700 Sender: hummes@eurecom.fr Message-ID: <33AFA76E.8B3@eurecom.fr> Date: Tue, 24 Jun 1997 12:54:38 +0200 From: Jakob Hummes Organization: Eurecom X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5 sun4u) MIME-Version: 1.0 To: rem-conf@es.net Subject: MBone Tools and Java Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I have some questions regarding the MBone tools; especially I'm interested in an audio conferencing tool like vat. I want to write a Java GUI for the MBone tools. The GUI would be written as components (JavaBeans) and such be part that may be assembled into other applications. Before I start I need more information about some points. 0) Did anyone do already the work??? 1) Are documented APIs for the tools available? For which tools? 2) Since the GUI is normally written in Tcl/Tk, their interface to C/C++ may be taken as startpoint for the Java GUI layer. Has the c/C++ implementation direct dependencies on the Tcl/Tk sources? 3) Are there any known traps I should be aware of? TIA, - Jakob -- WORK: Jakob Hummes EURECOM 2229, route des Cretes B.P. 193 06904 Sophia Antipolis Cedex FRANCE Tel: (+33) (0)4 93 00 26 70 WWW: http://www.eurecom.fr/~hummes Fax: (+33) (0)4 93 00 26 27 From rem-conf Tue Jun 24 10:16:22 1997 From rem-conf-request@es.net Tue Jun 24 10:16:21 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wgZ7G-0005ep-00; Tue, 24 Jun 1997 10:10:54 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Tue, 24 Jun 1997 10:09:38 -0700 (PDT) Message-Id: <199706241709.KAA20672@hille.msri.org> To: rem-conf@es.net From: mmadrid Reply-to: mmadrid@psc.edu Subject: Pittsburgh Supercomputing Center: Crystallography Workshop X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Pittsburgh Supercomputing Center: Crystallography Workshop Date: Jun 25, 1997 Time: 15:30 GMT 1 hours Contact: mmadrid@psc.edu URL: http://www.psc.edu/biomed/workshops/wk-97/crys97/crys97.html Description: The Pittsburgh Supercomputing Center will broadcast lectures by Prof. William Furey and Prof. Randy Read as they discuss PHASES and Maximum likelihood structure refinement. Workshop will also be broadcasted on Thursday and Saturday morning. Agenda and lecture notes, when available, can be found at the above-mentioned URL. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Tue Jun 24 15:00:06 1997 From rem-conf-request@es.net Tue Jun 24 15:00:05 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wgdQe-0000BO-00; Tue, 24 Jun 1997 14:47:12 -0700 Message-Id: <199706242146.XAA26817@piraya.electrum.kth.se> To: fenner@parc.xerox.com Cc: dino@geoplex.com, rem-conf@es.net From: Magnus Danielson Subject: Re: tunnels/mrouted In-Reply-To: Your message of "Mon, 23 Jun 1997 15:14:22 PDT" References: <97Jun23.151437pdt.177512@crevenia.parc.xerox.com> X-Mailer: Mew version 1.06 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 24 Jun 1997 23:46:54 +0200 Sender: e93_mda@drum.it.kth.se X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >>>>> "BF" == Bill Fenner writes: BF> "Edin (Dino) Hodzic" wrote: >> - is there any documentation which describes the 3.5 >> multicast. In particular, the interface between the kernel >> and mrouted, and the division of responsibilities between the >> kernel and mrouted w.r.t. multicast routing and forwarding? BF> Not really. The division is farily straightforward, though -- the BF> kernel forwards, mrouted makes the forwarding decision. If the kernel BF> gets a packet for which it doesn't have a forwarding cache entry, it BF> asks mrouted to install a forwarding cache entry for it. The kernel BF> has no state other than the forwarding cache that mrouted installs and BF> can't make any decisions on its own. >> - is there free BSD code I can take a look at in order to >> understand multicast 3.5? BF> All of FreeBSD, NetBSD and OpenBSD have the 3.5 multicast code. BF> They are each available from ftp.bsd.org . >> - is there any documentation describing the implementation of >> mrouted, other than its source code? BF> Unfortunately, no. There is however some description in TCP/IP Illustrated Volume 2 Chapter 14 covering mainly mrouted 2.0 implementation and touching 3.3. Cheers, Magnus From rem-conf Tue Jun 24 15:08:31 1997 From rem-conf-request@es.net Tue Jun 24 15:08:31 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wgdjA-0001Kt-00; Tue, 24 Jun 1997 15:06:20 -0700 Date: Tue, 24 Jun 1997 14:43:05 -0700 () From: Stephen Casner Reply-To: Stephen Casner To: rem-conf@es.net cc: "M. Reha Civanlar" Subject: Going to Last Call on draft-ietf-avt-mpeg-new-00.txt In-Reply-To: Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT working group: In May, I issued a working group last call for comments on draft-ietf-avt-mpeg-new-00.txt. This is an update, written by Reha Civanlar, to the RTP MPEG payload format specified in RFC 2038 to allow the packet loss resilience mechanisms to work for MPEG2 in addition to MPEG1. I stated a last call period of two weeks, but needed to give more time for a couple of volunteers to complete their reviews. No changes were requested, and no comments were received the rest of the working group, so we shall now proceed to the official IESG Last Call. The new RFC will again be at Proposed Standard status. Reha, please prepare an update to the Internet-Draft to incorporate the one wording change we discussed earlier (and any typos or other corrections you may have accumulated), and send that update to internet-drafts@ietf.org. Then I will send the request for Last Call to the IESG Secretary. -- Steve From rem-conf Wed Jun 25 00:56:10 1997 From rem-conf-request@es.net Wed Jun 25 00:56:09 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wgmp3-0004Oh-00; Wed, 25 Jun 1997 00:49:01 -0700 Message-ID: <01BC8111.98DD5340@dyn-max03-13.chi.ais.net> From: Stuart Johnstone To: 'Jakob Hummes' , "rem-conf@es.net" Subject: RE: MBone Tools and Java Date: Wed, 25 Jun 1997 00:11:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Yup. A version thereof in any case using GSM audio and shortly Dolby AC3. Take the time to peek at URL http://www.vosaic.com. There you can download a free version of the VOSAIC RadioStation for monkeying around with down at INRIA or your beautiful offices at Sophia Antinopolis....we miss seeing you all there. Prof. Campbell sends his regards. Regards, Stuart -----Original Message----- From: Jakob Hummes [SMTP:hummes@eurecom.fr] Sent: Tuesday, June 24, 1997 5:55 AM To: rem-conf@es.net Subject: MBone Tools and Java Hi, I have some questions regarding the MBone tools; especially I'm interested in an audio conferencing tool like vat. I want to write a Java GUI for the MBone tools. The GUI would be written as components (JavaBeans) and such be part that may be assembled into other applications. Before I start I need more information about some points. 0) Did anyone do already the work??? 1) Are documented APIs for the tools available? For which tools? 2) Since the GUI is normally written in Tcl/Tk, their interface to C/C++ may be taken as startpoint for the Java GUI layer. Has the c/C++ implementation direct dependencies on the Tcl/Tk sources? 3) Are there any known traps I should be aware of? TIA, - Jakob -- WORK: Jakob Hummes EURECOM 2229, route des Cretes B.P. 193 06904 Sophia Antipolis Cedex FRANCE Tel: (+33) (0)4 93 00 26 70 WWW: http://www.eurecom.fr/~hummes Fax: (+33) (0)4 93 00 26 27 From rem-conf Wed Jun 25 06:52:59 1997 From rem-conf-request@es.net Wed Jun 25 06:52:58 1997 Received: from list by mail1.es.net with local (Exim 1.61 #3) id 0wgsQU-00063f-00; Wed, 25 Jun 1997 06:48:02 -0700 Message-Id: <33B12767.62A8@hpl.hp.com> Date: Wed, 25 Jun 1997 15:12:55 +0100 From: Claudio Catania Reply-To: cld@hplb.hpl.hp.com Organization: HP Labs X-Mailer: Mozilla 3.01 (WinNT; I) Mime-Version: 1.0 To: rem-conf@es.net Subject: VAT.. help Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, Does anyone know where can I find the source code of VAT for Win32? Does anyone know why the latest version of VAt I found is dated June 96? Did people stop developing it? Does anyone know where can I find some complete documentation about this tool. Any pointer, articles, overview, instruction manuals, developers helpers, results from tests.... would be very useful. Are there any performance results for VAT and its voice codecs? Where are they? Claudio -- ---------------------------------------------------------- Claudio Catania Research engineer mailto:cld@hpl.hp.com Hewlett-Packard Laboratories Phone: +44 117 922 8235 Fax: +44 117 922 8003 Filton Road, Stoke Gifford Telnet: 312 8235 BS12 6QZ Bristol (U.K.) ---------------------------------------------------------- From rem-conf Wed Jun 25 14:58:29 1997 From rem-conf-request@es.net Wed Jun 25 14:58:28 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0wgzvP-0001o2-00; Wed, 25 Jun 1997 14:48:27 -0700 Message-ID: <33B1A25B.F43E407@faslab.com> Date: Wed, 25 Jun 1997 15:57:31 -0700 From: Charles Brauer Reply-To: brauer@faslab.com Organization: Fujitsu Network Communications X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: Please help X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Howdy: I am tantalizingly close to getting an mbone feed to work. My tunnel partner is BBN and my mrouted machine inside my firewall is a Sun SPARCstation that is running Solaris 2.51. My program guide is getting SDR announcements; but when I try to view any broadcast, I cannot seem to send IGMP group join requests. I am wondering if my problem is in BBN Cisco filters or if it is a configuration problem with mrouted. My mrouted.conf looks like: tunnel 204.161.60.33 192.42.110.249 metric 1 threshold 32 rate_limit 0 A trace of "netstat -M" on my mrouted machine looks like: Script started on Wed Jun 25 14:17:29 1997 berkeley 2 MBone/mtrace-5.1# ./netstat -M Virtual Interface Table Vif Thresh Rate_Lim Local-Address Remote-Addr Pkt_in Pkt_out 0 1 0 berkeley 1295 34917 1 32 0 berkeley paloalto-mbo 37866 0 Numvifs: 2 Multicast Forwarding Cache Origin-Subnet Mcastgroup #Pkts In-Vif Out-vifs/Forw-ttl demo-40.psc.edu SAP.MCAST.NET 1 1 0 (1) mbone1.csc.cuhk SAP.MCAST.NET 2 1 0 (1) miller-genuine- SAP.MCAST.NET 3 1 0 (1) irl.eecs.umich. SAP.MCAST.NET 1 1 0 (1) owe.isi.edu SAP.MCAST.NET 20 1 0 (1) 192.240.135.201 224.2.226.16 1 1 rot.rvs.uni-han SAP.MCAST.NET 1k 1 0 (1) 202.186.142.2 SAP.MCAST.NET 1 1 0 (1) 203.240.251.150 SAP.MCAST.NET 1 1 0 (1) paras-ss20.cisc 224.2.233.212 1 1 aem005.amc.anl. SAP.MCAST.NET 2 1 0 (1) wile.lbl.gov SAP.MCAST.NET 1 1 0 (1) 198.202.88.45 SAP.MCAST.NET 1 1 0 (1) polenta.pop-mg. SAP.MCAST.NET 2 1 0 (1) d01.hkt.net SAP.MCAST.NET 1 1 0 (1) donald.fokus.gm SAP.MCAST.NET 3 1 0 (1) Total no. of entries in cache: 16 berkeley 4 MBone/mtrace-5.1# exit script done on Wed Jun 25 14:18:42 1997 Any help will be greatly appreciated. Charles Brauer Fujitsu Advanced Software Lab 800 El Camino, #150 Menlo Park, California 94025 brauer@faslab.com (415) 325-8612, FAX (415) 325-6015 From rem-conf Thu Jun 26 03:33:33 1997 From rem-conf-request@es.net Thu Jun 26 03:33:32 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0whBhw-0004xI-00; Thu, 26 Jun 1997 03:23:20 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Thu, 26 Jun 1997 03:22:01 -0700 (PDT) Message-Id: <199706261022.DAA21600@hille.msri.org> To: rem-conf@es.net From: Reply-to: mbone@ust.hk Subject: Live Broadcast of Hong Kong Handover 1997 Event X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Live Broadcast of Hong Kong Handover 1997 Event Date: Jun 30, 1997 Time: 12:00 Hongkong 12 hours Contact: mbone@ust.hk URL: http://www.ust.hk/handover/mbone.html Description: The Hong Kong University of Science and Technology (HKUST) will broadcast a 24-hr live of Hong Kong 1997 Handover event from June 30 1200 to July 1 1200 (HKT). The broadcast is especially targeted for Asia Pacific countries. Video signal is received from the Pearl Channel (English channel) of the Television Broadcasts Limited (TVB). mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Jun 26 04:29:35 1997 From rem-conf-request@es.net Thu Jun 26 04:29:33 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0whCie-0005T8-00; Thu, 26 Jun 1997 04:28:08 -0700 Message-Id: <199706261026.UAA28652@sarang.kyungsung.ac.kr> To: "rem-conf@es.net" Subject: KR-Net'97 Workshop Broadcast Date: Thu, 26 Jun 97 20:24:53 -0500 From: Jong Kuk Lee X-Mailer: E-Mail Connection v2.5.03 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: KR-Net'97 Workshop Broadcast Date: 1st July, 1997 - 3th July 1997 Time: 02:00-10:00 (GMT) 10:00-18:00 (Korea) Contact: mbone@knc.or.kr URL & Schedule : http://sarang.kyungsung.ac.kr/Mbone/index-e.html Description: Mbone-kr(Mbone Group of Korea) will broadcast the KR-Net'97 Workshop in Seoul, Korea from 1st July to 3th July 1997, 02:00 - 10:00 GMT. Mbone-kr will broadcast a semina about Mbone, Multimedia, Internet Protocol, etc during 3 days. The broadcast is especially relaying from the spot about Preparation prosess & Interview (Speaker & People) during rest & lunch time. schedule http://sarang.kyungsung.ac.kr/Mbone/index-e.html From rem-conf Thu Jun 26 04:44:00 1997 From rem-conf-request@es.net Thu Jun 26 04:44:00 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0whCwd-0005pf-00; Thu, 26 Jun 1997 04:42:35 -0700 Message-Id: <199706261040.UAA28748@sarang.kyungsung.ac.kr> To: "rem-conf@es.net" Subject: KR-Net'97 Workshop Broadcast Date: Thu, 26 Jun 97 20:39:37 -0500 From: Jong Kuk Lee X-Mailer: E-Mail Connection v2.5.03 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: KR-Net'97 Workshop Broadcast Date: 1st July, 1997 - 3th July 1997 Time: 02:00-10:00 (GMT) 10:00-18:00 (Korea) Contact: mbone@knc.or.kr URL & Schedule : http://sarang.kyungsung.ac.kr/Mbone/index-e.html Description: Mbone-kr(Mbone Group of Korea) will broadcast the KR-Net'97 Workshop in Seoul, Korea from 1st July to 3th July 1997, 02:00 - 10:00 GMT. Mbone-kr will broadcast a semina about Mbone, Multimedia, Internet Protocol, etc during 3 days. The broadcast is especially relaying from the spot about Preparation process & Interview (Speaker & People) during rest & lunch time. schedule http://sarang.kyungsung.ac.kr/Mbone/index-e.html ------- FORWARD, End of original message ------- From rem-conf Thu Jun 26 08:13:51 1997 From rem-conf-request@es.net Thu Jun 26 08:13:49 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0whG5b-0006uo-00; Thu, 26 Jun 1997 08:04:03 -0700 Date: Thu, 26 Jun 97 11:03:59 EDT From: andrew@calvin.dgbt.doc.ca (Andrew Patrick) Message-Id: <9706261503.AA23677@calvin.dgbt.doc.ca> Reply-To: andrew@calvin.dgbt.doc.ca X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rem-conf@es.net, mbone@ISI.EDU, multicast@canarie.ca, merci@cs.ucl.ac.uk Subject: "MPoll" - Beta 1.1 release X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list As part of the MERCI project, I have been working on a new multicast application for real-time polling of opinions and ratings. "MPoll" was developed with the following uses in mind: - collecting quality ratings during multicast sessions - collecting opinions and votes during multicast collaborative work sessions - collecting opinions on general topics or current events MPoll may be useful during multicast sessions to get opinions from all the participants quickly and efficiently. It may also be useful for collecting quality and reception ratings during MBONE events. You can pick-up the current (Beta) version of MPoll at ftp://debra.dgbt.doc.ca/pub/mbone/MPoll/ source code and binaries for SunOS, Solaris, and WIN32 are available. Assistance in compiling MPoll for other platforms will be appreciated. Below are some more details about this program. You can also find more information at: http://debra.dgbt.doc.ca/mbone/MPoll/MPoll.html --------------------------------------------------------------------- Using MPoll ----------- Usage: mpoll [-D] [-V] [-l] [-t ttl] [-C "title"] address/port OPTIONS: -D : use default address and port (224.2.2.200/6666; for debugging) -V : print version number and exit -l : print logging information (for debugging) -C "title" : the theme title for the questions -t ttl : the multicast TTL (default = 15) MPoll normally requires specifying a multicast address and port. MPoll can be used by itself, or with other multicast tools such as VAT and VIC in an MBONE session. MPoll can be started from SDR once an appropriate "plugin" is installed (see below), or from the command line. Command options that MPoll accepts include the multicast TTL (-t), which defaults to 15, and a session title (-C), which defaults to "Unknown Theme". These are the same command options used by other multicast tools. Once MPoll is started, there is built-in help for each of the windows that explains the features and functions. How MPoll Works --------------- MPoll works by sending question and response packets to the multicast address, and listening for packets from other hosts. The users can create a new question, and this will become available to all the users who have joined that multicast session. As users answer the question, the responses are distributed to all the participants, where they are tallied and displayed. MPoll packets are redistributed periodically as long as the program is running, so that all current users will see all the results. Normally, MPoll will be left running continuously during a polling period or multicast session. MPoll uses a simple plain-text protocol for constructing multicast packets that is similar to the Session Description Protocol (SDP) used in SDR. There are currently 4 types of packets generated by MPoll: questions, remove question instructions, user responses, and membership information. MPoll creates a cache file in your home directory ("~/.mpoll_cache") for storing the questions and your responses from your last MPoll session. This allows you to quit and restart MPoll and have the questions and your responses for the last session reloaded. Installing MPoll ---------------- Binary Distribution ------------------- The MPoll binary file is a stand-alone C program that does not require any extra libraries in order to run. Simply copy the MPoll program to a directory that is in your path. Currently, binary distributions of MPoll are available for: - Solaris 2.5 - SunOS 4.1.4 - Win32 (Windows 95 & NT) Anyone who can help to compile MPoll for other platforms is asked to contact the author. Source Distribution ------------------- MPoll is written in C and Tcl/Tk. The development environment is: UNIX: - SPARC Solaris 2.5 - gcc version 2.7.2 - Tcl 7.6 / Tk 4.2 WIN32: - Microsoft Visual C++ 5.0 on Windows95 - Tcl/Tk 8.0 on Windows95 In addition, MPoll uses the Embedded Tk (ET) toolkit by Richard Hipp (http://users.vnet.net/drh/ET.html) for integrating C and Tcl/Tk programming. Version 1.7.1 of ET is included as part of the MPoll sources and will be built during the make process. No configuration procedure is available yet for MPoll. There are some configuration options at the beginning of the makefiles that you will probably have to set. MPoll has been developed under Solaris 2.5, so that is the default platform for make. Possible make commands are currently: For Solaris 2.5: "make" For SunOS 4.1.x: "make sunos" For Windows95: "nmake -f Makefile.vc" I would love to hear about any problems in building and running the program. Also, if you port MPoll to another platform, please contact me with any information about changes necessary, and if you can supply a binary for my archive site. The SDR Plugin -------------- Since MPoll is a new program, and polling is a new MBONE application, an appropriate media has not been defined in SDR. So, in order to use MPoll from SDR you must install a "plugin". The plugin provided in the distribution is sdr2.plugin.S53.control.udp.mpoll.mpoll and you should copy this to a "~/.sdr/plugins" directory on your system. See the SDR documentation for more information about plugins. Limitations ----------- - MPoll currently has no unicast support - MPoll is currently limited to 100 questions per session, and up to 10 possible answers per multiple-choice question. The question limit should be configurable be editing the MAX_TOPICS parameter in "mpoll.h", but changes to the MAX_RESPONSES parameter will probably not work. - MPoll should someday read the ~/.RTPdefaults file, and perhaps some other X resources - a function to remind users to update their responses should be added - we may need a function to edit an existing question Known Problems -------------- - this program is in a Beta stage of development. There are probably some features missing, and maybe some bugs. - MPoll was developed on Sun systems and has been tested on a few other platforms. More work on portability is required. - no attempt is made to do robust font selection, so MPoll will probably fail if the fonts I use are not on your system. See "mpoll.h" for the font definitions. - the command line args "-h or -help" dump core, use "--help" instead Acknowledgements ---------------- The protocol used in MPoll is fashioned after the SDP protocol used in SDR, and I thank Mark Handley, Van Jacobson, and other contributors for their work on SDP and SDR. I also used the SDR source code as an example while working on MPoll, and that code was useful for techniques like multicast socket management and periodic redistribution of packets. I learned a lot >from viewing other people's code, and I am sure that I made lots of mistakes, for which I am wholely responsible. Although I don't believe that I have used any of their code directly, to be safe I include their acknowledgement: This product includes software developed by the Computer Science Department at University College London Portions of the code used to support the WIN32 platform were copied >from the SDR program, and they were borrowed by Lawrence Berkeley National Laboratory. In accordance with the copyright notice, I hereby state: This product includes software developed by the Network Research Group at Lawrence Berkeley National Laboratory. Licence Terms ------------- Copyright (c) Communications Research Centre, Government of Canada 1997. All rights reserved. License is granted to copy and use this software, for research and evaluation purposes, provided that the Communications Research Centre is acknowledged in all documentation pertaining to any such copy or use. The Communications Research Centre grants no other licenses expressed or implied. Title, ownership rights, and intellectual property rights in the software shall remain with the Communications Research Centre. The Centre's name and the Government of Canada should not be used in any advertising without written permission. THE COMMUNICATIONS RESEARCH CENTRE MAKES NO REPRESENTATIONS CONCERNING EITHER THE MERCHANTABILITY OF THIS SOFTWARE OR THE SUITABILITY OF THIS SOFTWARE FOR ANY PARTICULAR PURPOSE. The software is provided "as is" without express or implied warranty of any kind. These notices must be retained in any copies of any part of this software. Author ------ Dr. Andrew Patrick Network Services & Interface Design Laboratory Communications Research Centre Industry Canada 3701 Carling Ave. P.O. Box 11490, Station 'H' Ottawa, ON CANADA K2H 8S2 Phone: (613) 990-4675 FAX: (613) 998-9648 E-Mail: andrew@calvin.dgbt.doc.ca WWW: http://debra.dgbt.doc.ca/~andrew -- Andrew Patrick, Ph.D. http://debra.dgbt.doc.ca/~andrew/ From rem-conf Thu Jun 26 12:36:16 1997 From rem-conf-request@es.net Thu Jun 26 12:36:15 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0whJab-0004MO-00; Thu, 26 Jun 1997 11:48:17 -0700 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-redundancy-00.txt, .ps Date: Thu, 26 Jun 1997 14:49:25 -0400 Sender: cclark@ietf.org Message-ID: <9706261449.aa13975@ietf.org> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : RTP Payload for Redundant Audio Data Author(s) : C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J. Bolot, A. Garcia S. Parisis Filename : draft-ietf-avt-rtp-redundancy-00.txt, .ps Pages : 10 Date : 06/25/1997 This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. The primary motivation for the scheme described herein is the development of audio conferencing tools for use with lossy packet networks such as the Internet Mbone, although this scheme is not limited to such applications. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-redundancy-00.txt". Or "get draft-ietf-avt-rtp-redundancy-00.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-rtp-redundancy-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-redundancy-00.txt". Or "FILE /internet-drafts/draft-ietf-avt-rtp-redundancy-00.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970625120526.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-redundancy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-redundancy-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970625120526.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Jun 26 23:48:56 1997 From rem-conf-request@es.net Thu Jun 26 23:48:55 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0whUif-0005Me-00; Thu, 26 Jun 1997 23:41:21 -0700 Date: Thu, 26 Jun 1997 23:33:32 -0700 (PDT) From: Stephen Casner To: Andrew Patrick cc: rem-conf@es.net Subject: Re: "MPoll" - Beta 1.1 release In-Reply-To: <9706261503.AA23677@calvin.dgbt.doc.ca> Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [cc list trimmed to rem-conf] Andrew, > - collecting quality ratings during multicast sessions I expect MPoll will be useful in a variety of scenarios, and may even be useful for collecting subjective quality measures from the participants. However, RTCP packet loss measurement, as displayed by rtpmon for example, is likely to be much more useful for measuring quality of reception in multicast sessions (that use RTP). That's because the reporting is automatic, so you don't have to coax a human to respond, and it is objective and relatively frequent. -- Steve From rem-conf Fri Jun 27 09:29:47 1997 From rem-conf-request@es.net Fri Jun 27 09:29:47 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0whde7-0007QC-00; Fri, 27 Jun 1997 09:13:15 -0700 Message-Id: <33B3E78F.4F4A1928@calvin.dgbt.doc.ca> Date: Fri, 27 Jun 1997 12:17:19 -0400 From: Andrew Patrick Reply-To: andrew@calvin.dgbt.doc.ca Organization: Communications Research Centre X-Mailer: Mozilla 4.01 [en] (Win95; I) Mime-Version: 1.0 To: Stephen Casner Cc: rem-conf@es.net Subject: Re: "MPoll" - Beta 1.1 release X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Stephen Casner wrote: > I expect MPoll will be useful in a variety of scenarios, and may even > be useful for collecting subjective quality measures from the > participants. However, RTCP packet loss measurement, as displayed by > rtpmon for example, is likely to be much more useful for measuring > quality of reception in multicast sessions (that use RTP). That's > because the reporting is automatic, so you don't have to coax a human > to respond, and it is objective and relatively frequent. I agree. Hopefully MPoll or something like it will be a useful addition to RTCP statistics and provide the subjective component that is needed. In addition, perhaps MPoll can allow us to collect feedback during sessions in a more systematic way then scribbling notes on the whiteboard. Of course you are right that the interesting task is coaxing humans to respond... -- Andrew Patrick, Ph.D. Communications Research Centre andrew@calvin.dgbt.doc.ca Ottawa, CANADA http://debra.dgbt.doc.ca/~andrew Phone: +1 613 990-4675 (Voice) From rem-conf Fri Jun 27 14:10:41 1997 From rem-conf-request@es.net Fri Jun 27 14:10:41 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0whiD0-0001Rh-00; Fri, 27 Jun 1997 14:05:34 -0700 From: rameshn@lucent.com Date: Fri, 27 Jun 97 17:04:59 EDT Original-From: ramesh@hoserve.ho.lucent.com Message-Id: <9706272104.AA01530@hopaw33> To: rem-conf@es.net Subject: IEEE INFOCOM'98 Paper Submission - Due July 15 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleagues, The deadline to submit papers for IEEE INFOCOM'98, July 15, is almost upon us. You may now submit papers by visiting the web site http://www-test1.cs.columbia.edu/~hgs/infocom/1998 and following the instructions therein. In case of problems, please contact the technical program chair, Ian Akyildiz, at infocom98@ee.gatech.edu. For all other information on INFOCOM'98 including the detailed call for papers, please visit one of the following web sites: USA: http://www.comsoc.org/~infocom98 Europe: http://www.cs.ucl.ac.uk/research/infocom98 Asia/Pacific: http://www.iss.nus.sg/INFOCOM Thanks and looking forward to your submissions, Ramesh Nagarajan. From rem-conf Fri Jun 27 16:02:03 1997 From rem-conf-request@es.net Fri Jun 27 16:02:03 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0whjyH-0002H2-00; Fri, 27 Jun 1997 15:58:29 -0700 X-Lotus-FromDomain: IBM RESEARCH From: "Dilip Kandlur" To: end2end-interest@ISI.EDU, rem-conf@es.net Message-ID: <852564C3.007DF4DC.00@watngi01.watson.ibm.com> Date: Fri, 27 Jun 1997 18:57:01 -0400 Subject: CFP: Multimedia Computing and Networking Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ======================================================================== === Multimedia Computing and Networking 1998 (MMCN98) January 26-28, 1998 San Jose, California Sponsored by SPIE and IS&T ACM SIG Multimedia Co-Sponsorship Pending ======================================================================== === Conference Chairs: Kevin Jeffay, University of North Carolina Dilip Kandlur, IBM T.J. Watson Research Center Timothy Roscoe, Persimmon Inc. Program Committee: Peter Beadle, University of Wollongong Ming-Syan Chen, National Taiwan University Wu-Chi Feng, Ohio State University Martin Freeman, Philips Research J.J. Garcia-Luna-Aceves, U.C. Santa Cruz Anoop Gupta, Stanford University Mark Hayter, DEC SRC Sugih Jamin, University of Michigan at Ann Arbor Paul Jardetzky, Sun Microsystems Chuck Kalmanek, AT&T Research Ian Leslie, University of Cambridge Sape Mullender, University of Twente Klara Nahrstedt U.I. Urbana-Champaign Guru Parulkar, Washington University Lawrence Rowe, U.C. Berkeley Debanjan Saha, IBM T.J. Watson Research Center Henning Schulzrinne, Columbia University Doug Shepherd, Lancaster University Brian Smith, Cornell University Cormac Sreenan, AT&T Research Ralf Steinmetz, T.U. Darmstadt Harrick Vin, University of Texas at Austin Jonathan Walpole, Oregon Graduate Institute Raj Yavatkar, Intel Corporation Hui Zhang, Carnegie Mellon University Advances in computer and networking technologies have fueled the rapid growth of research and development in multimedia computing and high-speed networking. As emerging multimedia technologies set higher performance levels at competitive costs, they are starting to enable and proliferate multimedia solutions in a spectrum of commercial and laboratory projects. The objective of this conference is to bring together researchers, developers, and practitioners working in all facets of multimedia computing and networking. The conference will serve as a forum for the dissemination of state-of-the-art research, development, and implementations of multimedia systems, technologies, and applications. Presenters will be encouraged to make multimedia presentations and demonstrate their solutions. Papers are solicited in all areas of multimedia, including, but not limited to: * Multimedia Computing Systems: - set-top technologies and operating systems - network computers and multimedia - hardware support and hardware accelerators - multimedia operating system services - real-time operating system services - video-on-demand servers and services * Multimedia Networking: - active networks - quality-of-service control and scheduling algorithms - synchronization mechanisms - mobile network architectures - wireless networks - access technologies and community networking - network and transport protocols - multimedia over heterogeneous networks * Multimedia and the Internet: - web servers and web-based services - internet appliances - push technologies - wide area caching architectures - data streaming and delivery mechanisms - compression - handling heterogeneous media formats * Measurement and modelling: - performance measurement of multimedia systems - statistical modelling of server traffic and server software - multimedia system simulations * Applications areas: - multimedia search engines and databases - entertainment and games - adaptive applications - synthetic animation - distributed virtual reality * User Interfaces and Authoring Systems: - media and user interaction - intelligent information access - interactive navigation schemes - multimedia authoring languages - authoring metaphors and editing techniques IMPORTANT INFORMATION FOR AUTHORS: --------------------------------- Please submit full papers for review. The submissions should not exceed 15 single-spaced pages including figures, tables, and references, using a typeface no smaller than 10 points. To expedite the reviewing process, please submit the paper electronically (in postscript format, through e-mail) to jeffay@cs.unc.edu Additionally, please send 1 hard copy of your paper to: Professor Kevin Jeffay Department of Computer Science, University of North Carolina at Chapel Hill Chapel Hill, NC 27599-3175 Phone : (919) 962-1938 E-mail : jeffay@cs.unc.edu Please also submit electronically (in plain text format) a cover page to jeffay@cs.unc.edu. Each cover page should contain: 1. Title of paper 2. Author names and affiliations 3. Name and address (both postal and electronic) of contact author 4. Abstract (500 words) 5. Keywords 6. Submission area (from the list of relevant areas in the call for papers) In addition, please also submit the 500 word abstract by accessing the web page at URL: http://www.spie.org/forms/ei98_submissions.html and following the instructions. Each paper will be reviewed by the members of the program committee. Authors of accepted papers will be asked to submit a camera-ready manuscript that will appear in the conference proceedings. Important Dates: ---------------- Electronic submission deadline: July 8, 1997 Deadline for receiving a hardcopy: July 11, 1997 Notification of acceptance: September 5, 1997 Camera-ready manuscripts due: October 21, 1997 The call for papers as well as the deadline information can also be obtained from http://www.persimmon.com/mmcn/ ==================================================================== From rem-conf Sat Jun 28 17:21:00 1997 From rem-conf-request@es.net Sat Jun 28 17:20:59 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0wi7ad-0007Hm-00; Sat, 28 Jun 1997 17:11:39 -0700 Date: Sat, 28 Jun 1997 17:10:41 -0700 From: gerard@hsmpka-122.Eng.Sun.COM (Gerard Fernando) Message-Id: <199706290010.RAA12237@halei.eng.sun.com> To: rem-conf@es.net Subject: Review of the bundled MPEG IETF draft Cc: casner@precept.com X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list As agreed at the AVT meeting in Memphis I have written a review of the bundled MPEG IETF draft. Gerard Fernando ---------------------------------------------------------------------------- Review of the bundled MPEG IETF draft [1] ----------------------------------------- This IETF draft describes a payload type for bundled MPEG2 encoded video and audio data to be used with RTP. There are two points on which I tend to have doubts about the usefulness of this proposal. One is on the argument for bundling. There are disadvantages with transporting of bundled MPEG data. The modularity inherent in having separate video and audio streams would be lost by having bundled MPEG2 data. This is admitted by the authors. I disagree with the authors on the premise that the benefits of transporting bundled MPEG data outweigh their disadvantages. There is another point on which I have doubts, and that is - why this proposal for bundling MPEG2 is any better than encapsulating MPEG2 Systems data. RFC2038 and the subsequent revision (draft-ietf-avt-mpeg-new-00.txt)[2] defines an encapsulation for MPEG2 and MPEG1 Systems streams. Admittedly, there is a very minor overhead (approximately 1%) in utilizing Systems streams as opposed to bundling audio and video streams. In my opinion, a 1% gain is not sufficient to justify this bundled MPEG proposal. The section on "data partitioning" for recovering in the event of packet loass appears to have some merit. It proposes separating the high priority (HP) information, like headers, from the low priority (LP) data stream. There are two proposals in this draft for transmitting the HP information. One proposal is to use a reliable protocol. This can lead to out-of-order arrival of HP data from LP data. The other proposal is to use layered multimedia transmission techniques for RTP[3]. Summary: The benefits of the bundled MPEG proposal are not sufficient to justify this IETF draft. The alternative definition for encapsulating MPEG data provide the necessary functionality to satisfy most requirements. The "data partitioning" part of the draft has sufficient merit for it to be separated from the rest so that it may be included with a proposal on error protection, or it may be included within a layered multimedia transmission proposal. References: [1] M. Reha Civanlar, Glenn L. Cash, Barry G. Haskell, "RTP Payload Format for Bundled MPEG," Internet Draft, draft-civanlar-bmpeg-01.txt, Feb,1997. [2] D. Hoffman, G. Fernando, V. Goyal, M. Civanlar "RTP Payload Format for MPEG1/MPEG2 Video," Internet Draft, draft-ietf-avt-mpeg-new-00.txt, April, 1997. [3] M. F. Speer, S. McCanne, "RTP Usage with Layered Multimedia Streams," Internet Draft, draft-speer-avt-layered-video-02.txt, December 1996. ======================================================================== Gerard Fernando Technology Development Group Sun Microsystems Computer Company Chief Technology Office 2550 Garcia Ave., MPK15-214 Mountain View, CA 94043-1100 Email: gerard.fernando@sun.com http://www.sun.com/ Phone: +1.415.786.6373 Fax: +1.415.786.6445 ======================================================================== From rem-conf Mon Jun 30 07:57:13 1997 From rem-conf-request@es.net Mon Jun 30 07:57:12 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0wihc6-0000yu-00; Mon, 30 Jun 1997 07:39:34 -0700 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-mpeg-new-01.txt Date: Mon, 30 Jun 1997 10:00:21 -0400 Sender: cclark@ietf.org Message-ID: <9706301000.aa07484@ietf.org> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for MPEG1/MPEG2 Video Author(s) : D. Hoffman, G. Fernando, V. Goyal, R. Civanlar Filename : draft-ietf-avt-mpeg-new-01.txt Pages : 14 Date : 06/27/1997 This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG System environments. The second is designed to provide maximum compatibility with other RTP-encapsulated media streams and future conference control work of the IETF. This memo is a revision of RFC 2038, an Internet standards track protocol, prepared for publication as a revised RFC. In this revision, the packet loss resilience mechanisms in Section 3.4 were extended to include additional picture header information required for MPEG2. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-mpeg-new-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-mpeg-new-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-mpeg-new-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970627172734.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-mpeg-new-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-mpeg-new-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970627172734.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Jun 30 15:59:44 1997 From rem-conf-request@es.net Mon Jun 30 15:59:44 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0wipJO-0003QX-00; Mon, 30 Jun 1997 15:52:46 -0700 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: rem-conf@es.net, mbone@isi.edu Subject: New sdr (2.4a6n) available Date: Mon, 30 Jun 1997 18:51:22 -0400 Message-ID: <2304.867711082@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list As several people have pointed out, the current versions of sdr contain a bug which can cause sdr to crash on receiving an announcement which is missing the session name field. As clones of sdr have been appearing increasingly frequently recently along with the accompanying broken announcements, I am releasing a version of sdr that is at least a little more hardened to receiving bogus messages. I hadn't planned to release another sdr version until I had the session invitation code properly conformant with the SIP spec we're about to release. The SIP code in sdr 2.4 is not compatible with the code in 2.3 or 2.2, and there's a fair chance 2.4a6 won't be compatible with 2.4a7 either. If you don't use session invitations this won't affect you. This version of sdr also uses the local administratively scoped range (see draft-ietf-mboned-admin-ip-scope-03.txt) for *local* announcements. This means previous versions of sdr won't hear its local announcements unless they are all configured to do so. Thus it's best if you upgrade all the platforms at a site simultaneously if you use sdr internally. This version of sdr makes these local announcements with a ttl of 15, but this ttl limit is only because I don't believe all the site-admin people out there have configured site borders for local scope yet. Please encourage your network administrator to do this. To comply with US export regulations, this version of sdr does not contain the encryption capabilities that were in sdr 2.3a1. Binaries for SunOS, Solaris, FreeBSD and Digital Unix as well as source code are all available from http://buttle.lcs.mit.edu/sdr/ As always, please let me know if you have any problems or if you build sdr for another platform. Cheers, Mark From rem-conf Mon Jun 30 19:49:10 1997 From rem-conf-request@es.net Mon Jun 30 19:49:09 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0wiswL-0004wD-00; Mon, 30 Jun 1997 19:45:13 -0700 Message-Id: <199707010245.TAA22114@icebox.vnd.tek.com> To: rem-conf@es.net Cc: tedb@auspex.vnd.tek.com Subject: draft-ietf-mboned-admin-ip-space-03.txt question From: Ted Brunner Date: Mon, 30 Jun 1997 19:45:21 -0700 Sender: tedb@icebox.tek.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I would like to check with the list that I understand the distinction between two of the address ranges defined in draft-ietf-mboned-admin-ip-space-03.txt, namely the IPv4 organizational local scope (239.192.0.0/14) and the IPv4 Local Scope (239.255.0.0/16). As I read it, the organizational local scope may be used throughout an intranet, extending through administrative boundries configured at routers, while the local scope cannot extend through such boundries. So if an intranet needs and establishes internal boundries, only the organizational local scope could be configured to reach every portion of the intranet. Right? More practically, for a multicast audio/video stream, intended for consumption within an Intranet; assuming I want to be able to administratively limit streams if necessary, but allow them the full scope of the Intranet if desired, a (default) multicast address should be selected from organizational local scope. On the other hand if I want them to always stay within the smallest multicast boundry (eg. for bandwidth considerations) the address should come from the Local Scope. Right? Ted Brunner Video and Networking Division Tektronix MS 50-490 ted.brunner@tek.com 14150 SW Karl Braun 503.627.1317 Beaverton OR 97005 From rem-conf Mon Jun 30 23:07:56 1997 From rem-conf-request@es.net Mon Jun 30 23:07:56 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0wiw0z-00068f-00; Mon, 30 Jun 1997 23:02:13 -0700 Date: Mon, 30 Jun 1997 18:33:21 -0400 Message-Id: <97063018332166@cards.cis.ohio-state.edu> From: jain@cards.cis.ohio-state.edu (Raj Jain, The Ohio State University) To: rem-conf@es.net Subject: Lectures on Internet [sent to @mbone] X-VMS-To: SMTP%"rem-conf@es.net" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list For the next six weeks, the Ohio State University is experimenting with live MBone transmission of our graduate class: CIS788.08q: Recent Advances in Networking If your organization has the MBone access, you are welcome to view it. The lectures covers recent topics such as ATM Networks, LAN Emulation, IP Switching, LAN Switching, Virtual LANs, Gigabit Ethernet, Multimedia over IP, Wireless LANs, Residential Broadband (Cable Modems), etc. The classes are held every Tuesday and Thursday, 5:30-6:45PM EST. For further information, please see http://www.cis.ohio-state.edu/~jain/cis788-97/schedule.htm Any comments or feedback should be sent to mbone@netlab.ohio-state.edu Thanks.