From rem-conf-request@es.net Mon Feb 1 09:55:56 1993 To: rem-conf@es.net Subject: ivs 2.1 availability Date: Mon, 01 Feb 93 18:28:46 +0100 From: Thierry TURLETTI Status: RO Content-Length: 139 X-Lines: 6 In order to save network bandwidth, you can retrieve ivs by anonymous ftp from export.lcs.mit.edu:contrib/ivs.tar.Z Thierry Turletti. From rem-conf-request@es.net Mon Feb 1 11:21:04 1993 To: rem-conf@es.net Subject: Audio and Video specs Date: Mon, 01 Feb 1993 14:09:40 -0500 From: Kannan Varadhan Content-Length: 272 Status: RO X-Lines: 11 Sorry if this is a stupid question, but, At the recent packet video conference at concert, I came across various spec terms such as G.711, G.712, H.261 etc. I was wondering what those specs were and how one could lay their hands on them. Thanks for any help, Kannan From rem-conf-request@es.net Mon Feb 1 12:43:10 1993 Date: Mon, 1 Feb 93 15:37:02 EST From: czei@sunpix.East.Sun.COM (Michael Czeiszperger - Sun NC Development Center) To: kannan@oar.net Subject: Re: Audio and Video specs Cc: rem-conf@es.net X-Sun-Charset: US-ASCII Content-Length: 535 Status: RO X-Lines: 22 > From rem-conf-request@es.net Mon Feb 1 14:37:18 1993 > To: rem-conf@es.net > Subject: Audio and Video specs > > > Sorry if this is a stupid question, but, > > At the recent packet video conference at concert, I came across various > spec terms such as G.711, G.712, H.261 etc. I was wondering what those > specs were and how one could lay their hands on them. > > Thanks for any help, > > > Kannan > You can order those specs and others from Omnicom PPI. Call them at (301) 309-3847. Michael Czeiszperger Audio Software From gong@concert.net Mon Feb 1 19:38:09 1993 From: Fengmin Gong Subject: Re: Dynamic assignment of multicast addresses To: braden@ISI.EDU (Bob Braden) Date: Mon, 1 Feb 1993 22:24:39 -0500 (EST) Cc: end2end-interest@ISI.EDU, rem-conf@es.net X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1302 Status: RO X-Lines: 35 Bob Braden wrote in a previous message: > > >Folks, (<--- a multicast address) > >VAT has started to make multicast real popular in Internetland, and >vendors are starting to ask how they can build products that need >dynamic assignment of multicast addresses. [Steve Deering, you've >put this off for many years now; your success is catching up with >you and us.] > >I understand that Van's SD has an algorithm for dynamic multicast >address allocation built in, so it's a solved problem and we're done, >right? > >Well, we can walk away, but maybe we owe the rest of the world a small >hint about how to proceed. I can think of several possible ways of >addressing this issue. (1) E2E could sponsor a teleconference of >anyone interested, to map a strategy. (2) We could suggest to the IESG >that an IETF WG in this area would be a Good Thing. (3) ?? > >Comments, anyone? > >Bob Braden > I've heard that a conference control BOF session is scheduled at the March IETF meeting in Columbus. It seems that multicast address assignment should be addressed along with conference directory services, all of which can comfortably be under the umbrella of conference control. I am not sure who will be organizing the session but really think these items will be good for the agenda. Fengmin Gong From rem-conf-request@es.net Mon Feb 1 19:48:12 1993 From: Fengmin Gong Subject: Re: Dynamic assignment of multicast addresses To: braden@ISI.EDU (Bob Braden) Date: Mon, 1 Feb 1993 22:24:39 -0500 (EST) Cc: end2end-interest@isi.edu, rem-conf@es.net X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1302 Status: RO X-Lines: 35 Bob Braden wrote in a previous message: > > >Folks, (<--- a multicast address) > >VAT has started to make multicast real popular in Internetland, and >vendors are starting to ask how they can build products that need >dynamic assignment of multicast addresses. [Steve Deering, you've >put this off for many years now; your success is catching up with >you and us.] > >I understand that Van's SD has an algorithm for dynamic multicast >address allocation built in, so it's a solved problem and we're done, >right? > >Well, we can walk away, but maybe we owe the rest of the world a small >hint about how to proceed. I can think of several possible ways of >addressing this issue. (1) E2E could sponsor a teleconference of >anyone interested, to map a strategy. (2) We could suggest to the IESG >that an IETF WG in this area would be a Good Thing. (3) ?? > >Comments, anyone? > >Bob Braden > I've heard that a conference control BOF session is scheduled at the March IETF meeting in Columbus. It seems that multicast address assignment should be addressed along with conference directory services, all of which can comfortably be under the umbrella of conference control. I am not sure who will be organizing the session but really think these items will be good for the agenda. Fengmin Gong From rem-conf-request@es.net Tue Feb 2 00:19:24 1993 Posted-Date: Mon 1 Feb 93 22:55:31-PST Date: Mon 1 Feb 93 22:55:31-PST From: Stephen Casner Subject: Re: More re conference services To: sylvia@dcs.qmw.ac.uk, rem-conf@es.net Mail-System-Version: Content-Length: 555 Status: RO X-Lines: 11 Sylvia, Your suggestion to consider as wide as possible a variety of AV applications is appreciated. You mention an assumption in the AVT document that the lifetime of conferences is unknown, but could you be more specific about what problems you believe accrue from that assumption? Would the protocol need to be changed if the lifetime were known? Or would that knowledge enable a signficant simplification of the protocol? This may be just one example; are there aspects of the protocol you think need to be changed? -- Steve Casner ------- From rem-conf-request@es.net Tue Feb 2 01:23:47 1993 From: Stuart Williams Subject: Re: Audio and Video specs To: kannan@oar.net (Kannan Varadhan) Date: Tue, 2 Feb 1993 08:48:22 +0000 (GMT) Cc: rem-conf@es.net X-Mailer: ELM [version 2.4 PL3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 5305 Status: RO X-Lines: 136 > From: Kannan Varadhan > > > Sorry if this is a stupid question, but, > > At the recent packet video conference at concert, I came across various > spec terms such as G.711, G.712, H.261 etc. I was wondering what those > specs were and how one could lay their hands on them. > > Thanks for any help, > > > Kannan > The following may be of interest - I haven't tried it out myself. Regards Stuart Williams. ---------------------------------------------------------- From: Carl Malamud Message-Id: <9211242252.AA05342@malamud.com> To: ietf@isi.edu Subject: Good news from the ITU ITU PRESS RELEASE/92-23 6 November 1992 WIDE RANGE OF ITU* DOCUMENTS NOW AVAILABLE ON-LINE: ITU STANDARDS TO BECOME ELECTRONICALLY ACCESSIBLE IN EARLY 93 An electronic document distribution service providing remote access to ITU documents - TELEDOC - became operational last week. Aimed at providing fast and timely access to ITU information to the world telecommunication and networking community, TELEDOC is a database containing at present: * CCITT and CCIR administrative documents * lists of contributions (substantive input/proposals) to CCITT and CCIR study groups * lists of CCITT reports and Recommendations (i.e. standards) * summaries of CCITT new or revised Recommendations * CCITT and CCIR meeting schedules and other information concerning Study Groups structures and activities. As from early next year, the full texts of all new and revised CCITT Recommendations (i.e. all standards approved after the publication of the Blue Book in 1988) will also be available from TELEDOC. In line with ITU publications policies, it is envisaged to expand TELEDOC information base according to identified needs and available resources. On TELEDOC's first day of operation, ITU Secretary- General Pekka Tarjanne stated: "The impact of the changing telecommunications environment makes it imperative that the ITU develop new approaches to the standardization process and find new ways to improve the efficiency of our work, new ways to disseminate the output of our work throughout the world. The implementation of TELEDOC", he said, "is undoubtedly a right step in this direction. Our ultimate goal is to make available on-line an entire library of ITU documents for a broad and transparent information exchange with all categories of interested users". TELEDOC is based on a X.400 document server which processes requests sent in by electronic mail. The TELEDOC Auto-Answering Mailbox accepts messages from the two most widely used E-mail systems: X.400 and Internet. Users without direct access to X.400 or Internet mail can use gateway services provided by major service providers (e.g. MCI or Compuserve). The electronic mail address of TELEDOC Auto-Answering Mailbox (TAM) is: X. 400 S=teledoc P=itu A=arcom C=ch Internet teledoc@itu.arcom.ch Document formats which are planned to be made available include ASCII, Microsoft RTF, Word for Windows, Postcript and CCITT ODA/ODIF. TELEDOC will be available on request, on a trial period of one year, at no access cost. For more information or to obtain a copy of the user's guide, please contact: Mr. Robert Shaw Miss Antoinette Bautista TELEDOC Project Coordinator EDH - CCITT Information Services CCITT Secretariat Department International Telecommunication International Union Telecommunication Union Place des Nations Place des Nations 1211 Geneva 20, Switzerland 1211 Geneva 20, Switzerland TEL: +41 22 730 5857 TEL: +41 22 730 5338/5554 FAX: +41 22 730 5853 FAX: +41 22 730 5337 X.400: G=antoinette; X.400: G=robert; S=shaw; S=bautista; A=arcom; P=itu; A=arcom; P=itu; C=ch C=ch Internet: shaw@itu.arcom.ch Internet: bautista@itu.arcom.ch _______________________________ * The International Telecommunication Union (ITU) was founded in 1865 and as such is the oldest inter- governmental organization. In 1947, it became a specialized agency of the United Nations and has a membership of 174 countries (4 November 1992). It is the international organization responsible for the regulation and planning of telecommunications worldwide, for the establishment of equipment and systems operating standards, for the coordination and dissemination of information required for the planning and operation of telecommunications services and within the United Nations system for the promotion of and contribution to the development of telecommunications and the related infrastructures. ----- End Included Message ----- From rem-conf-request@es.net Tue Feb 2 01:24:06 1993 To: Stephen Casner Cc: sylvia@dcs.qmw.ac.uk, rem-conf@es.net Subject: Re: More re conference services Date: Tue, 02 Feb 93 08:37:53 +0000 From: Jon Crowcroft Content-Length: 357 Status: RO X-Lines: 11 >document that the lifetime of conferences is unknown, but could you >be more specific about what problems you believe accrue from that >assumption? Would the protocol need to be changed if the lifetime cambirgde quote average voice mail message sizes (where one is live so may needs some sort of realtimeish networking) as being 17 secs... jon From schooler@ISI.EDU Tue Feb 2 02:12:38 1993 Date: Tue, 2 Feb 93 01:58:14 PST From: schooler@ISI.EDU Posted-Date: Tue, 2 Feb 93 01:58:14 PST To: braden@ISI.EDU, gong@concert.net Subject: Re: Dynamic assignment of multicast addresses Cc: end2end-interest@ISI.EDU, rem-conf@es.net, schooler@ISI.EDU Content-Length: 9051 Status: RO X-Lines: 199 >From: Fengmin Gong >Subject: Re: Dynamic assignment of multicast addresses >To: braden@ISI.EDU (Bob Braden) >Date: Mon, 1 Feb 1993 22:24:39 -0500 (EST) >Cc: end2end-interest@ISI.EDU, rem-conf@es.net > >Bob Braden wrote in a previous message: >> >> >>Folks, (<--- a multicast address) >> >>VAT has started to make multicast real popular in Internetland, and >>vendors are starting to ask how they can build products that need >>dynamic assignment of multicast addresses. [Steve Deering, you've >>put this off for many years now; your success is catching up with >>you and us.] >> >>I understand that Van's SD has an algorithm for dynamic multicast >>address allocation built in, so it's a solved problem and we're done, >>right? >> >>Well, we can walk away, but maybe we owe the rest of the world a small >>hint about how to proceed. I can think of several possible ways of >>addressing this issue. (1) E2E could sponsor a teleconference of >>anyone interested, to map a strategy. (2) We could suggest to the IESG >>that an IETF WG in this area would be a Good Thing. (3) ?? >> >>Comments, anyone? >> >>Bob Braden >> > >I've heard that a conference control BOF session is scheduled at the >March IETF meeting in Columbus. It seems that multicast address >assignment should be addressed along with conference directory services, >all of which can comfortably be under the umbrella of conference >control. I am not sure who will be organizing the session but really >think these items will be good for the agenda. > >Fengmin Gong Bob, Fengmin, I have scheduled two conference control BOF sessions for the March IETF in Columbus. The intent is to poll peoples' interest in this topic, and define the scope of a potential working group, if deemed useful. I plan to post more details about the agenda to the rem-conf mailing list within the next week or so. For those of you not on the rem-conf mailing list, I've appended the minutes from the confctrl discussions held at the November IETF for context. The group is likely to focus on the development of a session layer control protocol that would perform higher layer functions than the protocol proposed in the Ausio/Video Transport WG. It would accommodate a (small) range of conference styles -- beyond but including the unmoderated sessions already available through LBL's vat, PARC's nv, BBN's dvc, et al. Multicast address assignment is a service to which a conference control protocol must interface. Therefore I think a discussion to map out a strategy for coordinated address assignment would be a Good Thing. However, I don't believe that the confctrl group is the right forum for the discussion. One motivation for spawning a confctrl group, separate from RemConf, was to identify and work on one component of the overall Internet teleconferencing architecture. I would prefer that confctrl not become the umbrella group for all conferencing issues :-) Either approach, (1) or (2), make better sense to me. I do not have any strong feelings about the benefits of one over the other, but know that someone should be tackling this issue while multicast address usage is still low. Eve ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ During the RemConf BOF, there was a quorum of individuals interested in what has been referred to as "conference control" or "connection management". Subsequently we held two impromptu (i.e., previously unscheduled) BOF sessions to discuss what, if anything, we as a group might be able to contribute to the remote conferencing architecture effort. Below are minutes from those sessions. Thanks goes to Dean Blackketter for acting as scribe. Although we will continue to post information of general interest to the rem-conf mailing list, we have set up a more narrowly focused mailing list, confctrl@isi.edu, for detailed discussions in the area of conference control. To join the list, send a request to confctrl-request@isi.edu. Conference Control BOF November 16 & 17 IETF, Washington, D.C. One task of the initial BOF sessions was actually to find a suitable definition for "conference control", since the topic has been bandied about for some time in the Remote Conferencing BOF and the Audio/Video Transport WG. By broadly defining multimedia conferencing as collaborations in two dimensions (members and media), we defined conference control as the management and coordination of (multiple) conference members in (multiple) media. For example, three aspects of conference control might include session, connection and configuration management; session management entails who is involved in a conference, connection management involves the topology of who is seeing whom in each media, and configuration management is the negotiation of differences in end-system capabilities. How does conference control pertain to the ongoing RemConf efforts for an overall remote conferencing architecture, and in particular to the developments in the AVT WG of a real-time transport protocol? We agreed that there is a need for a session layer control protocol to perform higher layer functions than the protocol proposed in the AVT WG. We identified the beginnings of some design criteria for this protocol. First, it should be kept simple, yet extensible. We would like for it to accommodate a range of session styles -- beyond the unmoderated sessions already available through vat, dvc, nv et al. We also recognized the need to separate short-term from long-term functionality goals. We brainstormed about which functions MUST be supported versus which we would like to have supported. It falls out of our definition for conference control that, at minimum, support is needed for both membership and media control. Membership control might include admission policies (such as user identification, user payment, meeting sponsorship), whereas media control might encompass capability descriptions, synchronization policies, and floor control (media focus). In both dimensions, session setup, maintenance and/or modification must be supported. Other features deemed important but probably of lower priority included security (in the form of authentication and encryption), as well as feedback channels for bandwidth balancing. We also listed outside services to which we expect a conference control protocol to interface: a suite of directory services for cataloguing users, conferences, and shared devices; bandwidth allocation and reservation mechanisms; and a scheme for multicast address allocation. Our assumption is that eventually these outside services will be available. To understand the range of capabilities to support in a conference control protocol, we explored the types of sessions that might arise. Our wishlist included a continuum of session scenarios (although the picture below only lists a sample from the full range and only crudely approximates an ordering). "Secure" variations on these meetings were also discussed. impromptu hallway meetings classroom seminar pay-per-view |-------|-------|--------|-------|-------|-------|-------|-------| pt2pt arch design panel lecture TV phone review/ discussion/ broadcast call "quilting bee" presidential debate Observations made about the spectrum were that there are different types of participation (active and passive), that there are gradations of identification policies (known vs anonymous participants), that there may be extreme variations in the degree of interconnectivity among participants, etc. We discussed that for simplicity (and implementation) sake, we are likely to need to select a small number of session types that the protocol should support. A rough break down into four general session models was presented: 1. Point-to-point calls 2. Small, tightly-controlled sessions: N-way interconnectivity 3. Medium-sized, loosely-controlled sessions: lighter-weight model 4. Very large, fixed sessions: unidirectional broadcasts There was discussion that other standards bodies (CCITT) have explored issues in some aspects of connection control (for B-ISDN). In addition, existing prototype conferencing tools should be examined for leads on tradeoffs regarding conference management. Attendees: Dean Blackketter deanb@apple.com Wo Chang wchang@nist.gov Osmand DeSouza osmund.desouza@att.com Hans Eriksson hans@sics.se Don Hoffman hoffman@eng.sun.com Oliver Jones oj@pictel.com Jim Knowles jknowles@binky.arc.nasa.gov Bill Manning bmanning@rice.edu Kathleen Nichols nichols@apple.com Jim Perchik perchik@athena.mit.edu Eve Schooler schooler@.isi.edu Henning Schulzrinne hgs@research.att.com Scott Stein scotts@apple.com Thierry Turletti turletti@sophia.inria.fr Abel Weinrib abel@bellcore.com From rem-conf-request@es.net Tue Feb 2 02:15:53 1993 Date: Tue, 2 Feb 93 01:58:14 PST From: schooler@ISI.EDU Posted-Date: Tue, 2 Feb 93 01:58:14 PST To: braden@ISI.EDU, gong@concert.net Subject: Re: Dynamic assignment of multicast addresses Cc: end2end-interest@ISI.EDU, rem-conf@es.net, schooler@ISI.EDU Content-Length: 9051 Status: RO X-Lines: 199 >From: Fengmin Gong >Subject: Re: Dynamic assignment of multicast addresses >To: braden@ISI.EDU (Bob Braden) >Date: Mon, 1 Feb 1993 22:24:39 -0500 (EST) >Cc: end2end-interest@ISI.EDU, rem-conf@es.net > >Bob Braden wrote in a previous message: >> >> >>Folks, (<--- a multicast address) >> >>VAT has started to make multicast real popular in Internetland, and >>vendors are starting to ask how they can build products that need >>dynamic assignment of multicast addresses. [Steve Deering, you've >>put this off for many years now; your success is catching up with >>you and us.] >> >>I understand that Van's SD has an algorithm for dynamic multicast >>address allocation built in, so it's a solved problem and we're done, >>right? >> >>Well, we can walk away, but maybe we owe the rest of the world a small >>hint about how to proceed. I can think of several possible ways of >>addressing this issue. (1) E2E could sponsor a teleconference of >>anyone interested, to map a strategy. (2) We could suggest to the IESG >>that an IETF WG in this area would be a Good Thing. (3) ?? >> >>Comments, anyone? >> >>Bob Braden >> > >I've heard that a conference control BOF session is scheduled at the >March IETF meeting in Columbus. It seems that multicast address >assignment should be addressed along with conference directory services, >all of which can comfortably be under the umbrella of conference >control. I am not sure who will be organizing the session but really >think these items will be good for the agenda. > >Fengmin Gong Bob, Fengmin, I have scheduled two conference control BOF sessions for the March IETF in Columbus. The intent is to poll peoples' interest in this topic, and define the scope of a potential working group, if deemed useful. I plan to post more details about the agenda to the rem-conf mailing list within the next week or so. For those of you not on the rem-conf mailing list, I've appended the minutes from the confctrl discussions held at the November IETF for context. The group is likely to focus on the development of a session layer control protocol that would perform higher layer functions than the protocol proposed in the Ausio/Video Transport WG. It would accommodate a (small) range of conference styles -- beyond but including the unmoderated sessions already available through LBL's vat, PARC's nv, BBN's dvc, et al. Multicast address assignment is a service to which a conference control protocol must interface. Therefore I think a discussion to map out a strategy for coordinated address assignment would be a Good Thing. However, I don't believe that the confctrl group is the right forum for the discussion. One motivation for spawning a confctrl group, separate from RemConf, was to identify and work on one component of the overall Internet teleconferencing architecture. I would prefer that confctrl not become the umbrella group for all conferencing issues :-) Either approach, (1) or (2), make better sense to me. I do not have any strong feelings about the benefits of one over the other, but know that someone should be tackling this issue while multicast address usage is still low. Eve ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ During the RemConf BOF, there was a quorum of individuals interested in what has been referred to as "conference control" or "connection management". Subsequently we held two impromptu (i.e., previously unscheduled) BOF sessions to discuss what, if anything, we as a group might be able to contribute to the remote conferencing architecture effort. Below are minutes from those sessions. Thanks goes to Dean Blackketter for acting as scribe. Although we will continue to post information of general interest to the rem-conf mailing list, we have set up a more narrowly focused mailing list, confctrl@isi.edu, for detailed discussions in the area of conference control. To join the list, send a request to confctrl-request@isi.edu. Conference Control BOF November 16 & 17 IETF, Washington, D.C. One task of the initial BOF sessions was actually to find a suitable definition for "conference control", since the topic has been bandied about for some time in the Remote Conferencing BOF and the Audio/Video Transport WG. By broadly defining multimedia conferencing as collaborations in two dimensions (members and media), we defined conference control as the management and coordination of (multiple) conference members in (multiple) media. For example, three aspects of conference control might include session, connection and configuration management; session management entails who is involved in a conference, connection management involves the topology of who is seeing whom in each media, and configuration management is the negotiation of differences in end-system capabilities. How does conference control pertain to the ongoing RemConf efforts for an overall remote conferencing architecture, and in particular to the developments in the AVT WG of a real-time transport protocol? We agreed that there is a need for a session layer control protocol to perform higher layer functions than the protocol proposed in the AVT WG. We identified the beginnings of some design criteria for this protocol. First, it should be kept simple, yet extensible. We would like for it to accommodate a range of session styles -- beyond the unmoderated sessions already available through vat, dvc, nv et al. We also recognized the need to separate short-term from long-term functionality goals. We brainstormed about which functions MUST be supported versus which we would like to have supported. It falls out of our definition for conference control that, at minimum, support is needed for both membership and media control. Membership control might include admission policies (such as user identification, user payment, meeting sponsorship), whereas media control might encompass capability descriptions, synchronization policies, and floor control (media focus). In both dimensions, session setup, maintenance and/or modification must be supported. Other features deemed important but probably of lower priority included security (in the form of authentication and encryption), as well as feedback channels for bandwidth balancing. We also listed outside services to which we expect a conference control protocol to interface: a suite of directory services for cataloguing users, conferences, and shared devices; bandwidth allocation and reservation mechanisms; and a scheme for multicast address allocation. Our assumption is that eventually these outside services will be available. To understand the range of capabilities to support in a conference control protocol, we explored the types of sessions that might arise. Our wishlist included a continuum of session scenarios (although the picture below only lists a sample from the full range and only crudely approximates an ordering). "Secure" variations on these meetings were also discussed. impromptu hallway meetings classroom seminar pay-per-view |-------|-------|--------|-------|-------|-------|-------|-------| pt2pt arch design panel lecture TV phone review/ discussion/ broadcast call "quilting bee" presidential debate Observations made about the spectrum were that there are different types of participation (active and passive), that there are gradations of identification policies (known vs anonymous participants), that there may be extreme variations in the degree of interconnectivity among participants, etc. We discussed that for simplicity (and implementation) sake, we are likely to need to select a small number of session types that the protocol should support. A rough break down into four general session models was presented: 1. Point-to-point calls 2. Small, tightly-controlled sessions: N-way interconnectivity 3. Medium-sized, loosely-controlled sessions: lighter-weight model 4. Very large, fixed sessions: unidirectional broadcasts There was discussion that other standards bodies (CCITT) have explored issues in some aspects of connection control (for B-ISDN). In addition, existing prototype conferencing tools should be examined for leads on tradeoffs regarding conference management. Attendees: Dean Blackketter deanb@apple.com Wo Chang wchang@nist.gov Osmand DeSouza osmund.desouza@att.com Hans Eriksson hans@sics.se Don Hoffman hoffman@eng.sun.com Oliver Jones oj@pictel.com Jim Knowles jknowles@binky.arc.nasa.gov Bill Manning bmanning@rice.edu Kathleen Nichols nichols@apple.com Jim Perchik perchik@athena.mit.edu Eve Schooler schooler@.isi.edu Henning Schulzrinne hgs@research.att.com Scott Stein scotts@apple.com Thierry Turletti turletti@sophia.inria.fr Abel Weinrib abel@bellcore.com From braden@ISI.EDU Tue Feb 2 09:01:00 1993 Date: Tue, 2 Feb 1993 08:50:08 -0800 From: braden@ISI.EDU (Bob Braden) To: braden@ISI.EDU, gong@concert.net Subject: Re: Dynamic assignment of multicast addresses Cc: end2end-interest@ISI.EDU, rem-conf@es.net Content-Length: 906 Status: RO X-Lines: 26 > > > > I've heard that a conference control BOF session is scheduled at the > March IETF meeting in Columbus. It seems that multicast address > assignment should be addressed along with conference directory services, > all of which can comfortably be under the umbrella of conference > control. I am not sure who will be organizing the session but really > think these items will be good for the agenda. > > Fengmin Gong > > Fengmin, Input from the conference control BOF would be useful, but I don't believe it is sufficient. Let me make the analogy of asking the FTP committee to design TCP. Although it is conferencing that has popularized multicasting, IP multicasting has many important applications other than teleconferencing. As a matter of fact, the vendor request that spurred my question had to do with the logical addressing capability of multicast, locating things. Bob Braden From rem-conf-request@es.net Tue Feb 2 09:08:27 1993 Date: Tue, 2 Feb 1993 08:50:08 -0800 From: braden@ISI.EDU (Bob Braden) To: braden@ISI.EDU, gong@concert.net Subject: Re: Dynamic assignment of multicast addresses Cc: end2end-interest@ISI.EDU, rem-conf@es.net Content-Length: 906 Status: RO X-Lines: 26 > > > > I've heard that a conference control BOF session is scheduled at the > March IETF meeting in Columbus. It seems that multicast address > assignment should be addressed along with conference directory services, > all of which can comfortably be under the umbrella of conference > control. I am not sure who will be organizing the session but really > think these items will be good for the agenda. > > Fengmin Gong > > Fengmin, Input from the conference control BOF would be useful, but I don't believe it is sufficient. Let me make the analogy of asking the FTP committee to design TCP. Although it is conferencing that has popularized multicasting, IP multicasting has many important applications other than teleconferencing. As a matter of fact, the vendor request that spurred my question had to do with the logical addressing capability of multicast, locating things. Bob Braden From rem-conf-request@es.net Tue Feb 2 09:58:43 1993 From: Fengmin Gong Subject: Re: Dynamic assignment of multicast addresses To: braden@ISI.EDU (Bob Braden) Date: Tue, 2 Feb 1993 12:55:06 -0500 (EST) Cc: end2end-interest@isi.edu, rem-conf@es.net X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 606 Status: RO X-Lines: 19 Bob Braden wrote in a previous message: > >Fengmin, > >Input from the conference control BOF would be useful, but I don't >believe it is sufficient. Let me make the analogy of asking the FTP >committee to design TCP. Although it is conferencing that has >popularized multicasting, IP multicasting has many important >applications other than teleconferencing. As a matter of fact, the >vendor request that spurred my question had to do with the logical >addressing capability of multicast, locating things. > >Bob Braden > > Thanks for making that point so clear. I agree whole heartedly. Fengmin Gong From gong@concert.net Tue Feb 2 10:03:18 1993 From: Fengmin Gong Subject: Re: Dynamic assignment of multicast addresses To: braden@ISI.EDU (Bob Braden) Date: Tue, 2 Feb 1993 12:55:06 -0500 (EST) Cc: end2end-interest@ISI.EDU, rem-conf@es.net X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 606 Status: RO X-Lines: 19 Bob Braden wrote in a previous message: > >Fengmin, > >Input from the conference control BOF would be useful, but I don't >believe it is sufficient. Let me make the analogy of asking the FTP >committee to design TCP. Although it is conferencing that has >popularized multicasting, IP multicasting has many important >applications other than teleconferencing. As a matter of fact, the >vendor request that spurred my question had to do with the logical >addressing capability of multicast, locating things. > >Bob Braden > > Thanks for making that point so clear. I agree whole heartedly. Fengmin Gong From rem-conf-request@es.net Wed Feb 3 22:57:49 1993 From: malcolm@nutmeg.cs.ntu.edu.au (Malcolm Caldwell) Subject: video samples and sizes To: rem-conf@es.net Date: Thu, 4 Feb 1993 15:50:40 +0930 (CST) Reply-To: malcolm@it.ntu.edu.au (Malcolm Caldwell) X-Mailer: ELM [version 2.4 PL5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 732 Status: RO X-Lines: 21 Hello, I am preparing a paper of the local (very local) unix users group meeting on multimedia developments. I recently took place in some conferencing (the Australian networkshop) auidocast. Unfortunately due to the small capacity of our link I was not able to see any video. What I would like is this: 1) Could someone tell me what the average bandwidth used by nv (or similar) is? 2) Could someone give me some video recorded by the nv record tool? That way I would be able to get an idea of what I am missing! Thanks. -- Malcolm Caldwell Email: malcolm@pandanus.ntu.edu.au Technical Officer Ph: +61 89 466546 Computer Science Fax: +61 89 270612 Northern Territory University, Darwin Australia From rem-conf-request@es.net Fri Feb 5 09:48:12 1993 To: rem-conf@es.net, cscw-list@group-id.co.uk Cc: mm-local@cs.ucl.ac.uk Subject: UCL MM ftp archive Date: Fri, 05 Feb 93 17:36:14 +0000 From: Mark Handley Content-Length: 472 Status: RO X-Lines: 16 As I have received quite a few requests for info on Shared-X (the DEC version, ShX), I've sorted out our Multimedia ftp archive. There's a number of papers and also the sources with a number of bug fixes to Shared-X. The archive is on cs.ucl.ac.uk, in the car directory. The README file contains a contents list. Any suggestions or comments would be welcomed. Mark Handley, MICE Project, Dept of Computer Science, University College London. M.Handley@cs.ucl.ac.uk From rem-conf-request@es.net Sun Feb 7 20:40:51 1993 Date: Mon, 8 Feb 1993 15:27:47 +1100 From: btonkin@lindblat.cc.monash.edu.au (Bruce Tonkin) To: rem-conf@es.net Subject: IEEE Workshop on Visual Signal Processing and Communications Content-Length: 6263 Status: RO X-Lines: 179 FINAL CALL-FOR-PAPERS ===================== IEEE WORKSHOP ON VISUAL SIGNAL PROCESSING AND COMMUNICATIONS 20-22 September, 1993 Hilton Hotel, Melbourne, Australia Sponsored by: IEEE Circuits and Systems Society, U.S.A. Siemens Ltd., Australia AOTC TRL, Australia Co-sponsored by: IEEE, Victoria Section, Australia The Institution of Engineers, Australia The Institution of Electrical Engineers (U.K.), Victoria Centre, Australia The objective of this workshop is to provide a forum for recent developments and future directions in visual signal processing and communications. The workshop will feature sessions with both invited and contributed papers and tutorial sessions. Suggested topics include: * Video coding and signal processing, * VLSI circuits and systems for video signal processing and communications, * Narrow and broadband video communications, * Packet video for ATM networks, * Systems and architecture of high definition television, * 3-D image processing systems, * Multi- dimensional signal processing, * Multimedia communication systems, * Image archiving and retrieval systems, * Wavelets applied in image processing, * Pattern recognition and neural networks. Prospective authors are invited to submit four copies of extended summaries (1000- 2000 words) of their papers to the Technical Program Chairman: Dr King N. Ngan Department of Electrical and Computer Systems Engineering Monash University Clayton, Victoria 3168 Australia Fax: +61 3 565 3454 Email: king@uvc.eng.monash.edu.au Authors are requested to indicate the equipment required for the presentation of their papers. Author's Schedule: ================= Submission of Summaries: 31 March 1993 Notification of Acceptance: 15 June 1993 Camera-ready Manuscripts: 15 August 1993 For workshop details, please contact the General Chairman, Dr Khee K. Pang at the above address (Telephone: +61 3 565 3482, Fax: +61 3 565 3454, Email:khee@uvc.eng.monash.edu.au). ORGANISING COMMITTEE ==================== General Chair Deputy General Chair Technical Chair ------------- -------------------- --------------- Khee K. Pang Fred J. Symons King N. Ngan Monash Univ Monash Univ Monash Univ Local Organisation Finance International Liaison ------------------ ------- & Tutorials Michael Biggar Phillip Stevens --------------------- Telecom Research Siemens Ltd. John Princen Laboratories Telecom Research Laboratories International Advisory Committee ================================ Chairman Zhengming Chai Francis Jutand Ming L. Liou Institute of Electronics ENST (France) HKUST (Hong Kong) Academia Sinica (China) Yrjo Neuvo Takao Nishitani Peter van Otterloo Tampere University NEC (Japan) Phillips Research labs of Technology (The Netherlands) (Finland) Kou-Hu Tzou Sarah Rajala Hsueh-Ming Hang Comsat (USA) North Carolina State National Chiao Tung University (USA) University (Taiwan) Byeong GI Lee Bede Liu Seoul National Princeton University University (Korea) (USA) Peter Pirsch Lance Wu University of Hannover Computer and Communications (Germany) Research Laboratories (Taiwan) Xinggang Lin Sanjit K. Mitra Tsinghua University University of California (China) at Santa Barbara (USA) VIDEO AND IMAGE CODING ONE DAY TUTORIAL ======================================= 20 September 1993 Hilton Hotel Melbourne, Australia Video and Image Coding ---------------------- Over the last few years there have been exciting advances in Video and Image Coding. These advances include new algorithms, real-time implementations, and the availability of high quality standards. Matching these developments have been advances in networking and storage technology. ISDN is becoming widely available and Broadband ISDN technology looks set to bcome widespread in the near future for both public networks and LAN's. Optical disk storage can now support hours of compressed full motion video. The result of all this will be an explosive growth in a range of new digital image and video based services. As image and video coding technology matures it is becoming increasingly relevant to a wide range of organizations and it is providing a range of opportunities for innovative products and services such as interactive multimedia, digital TV and High Definition TV, and the infamous Videophone. Given the rapid developments taking place it is timely to provide a tutorial so that a wider audience can become familiar with this key technology. Objective --------- The one day tutorial, to be presented by recognized experts, will cover coding techniques at both an introductory and advanced level. There will be a focus on Image and Video coding standards, implementations and digital video support on broadband networks. The tutorial will be of interest to newcomers in this field and more experienced delegates. By providing attendees with a background in compression technology, the tutorial will make an excellent introduction to the technical sessions in the Visual Signal Processing and Communications wokshop, which will be held on the following two days. Topic Covered ------------- * Discrete Cosine Transform based coding and motion compensation * Joint Photographic Expert Groups's (JPEG) image coding system * CCITT H.261 standard * Moving Picture Experts Group (MPEG) phase 1 and phase 2 standards * Digital TV and HDTV coding * Scalable coding systems * Packet video coding * Video support on broadband networks * Implementation of video coding algorithms From rem-conf-request@es.net Tue Feb 9 04:43:36 1993 To: rem-conf@es.net Subject: Shared X blues Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam Phone: +31 20 5924098(work), +31 20 5924199 (fax), +31 20 6160335(home) X-Last-Band-Seen: Betty Goes Green (Sleepin, 4-2) X-Mini-Review: hmm... still undecided. Date: Tue, 09 Feb 1993 12:46:34 +0100 From: Jack Jansen Content-Length: 720 Status: RO X-Lines: 13 I've been looking at shared-X and xtv recently, and neither of them seems to work for me. (Platform: SGI Indigo running 4.0.5F, with X11R4). Aside from the fact that both needed a bit of hacking to get them running they simply don't work: on startup shared-X eats all memory it can find and then dumps a 64Mb corefile, tvx works slightly longer but crashes as soon as you try to start tools. Therefore my next question: are there any other X window sharers, preferably either more robust or proven on SGI platforms? -- Jack Jansen | If I can't dance I don't want to be part of Jack.Jansen@cwi.nl | your revolution -- Emma Goldman uunet!cwi.nl!jack G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl From rem-conf-request@es.net Tue Feb 9 10:14:06 1993 To: Jack Jansen Cc: rem-conf@es.net Subject: Re: Shared X blues Date: Tue, 09 Feb 93 09:51:48 -0800 From: redell@src.dec.com X-Mts: smtp Content-Length: 103 Status: RO X-Lines: 5 Try contacting John Bazik at Brown University about XMX. His email address is jsb@cs.brown.edu. Dave From rem-conf-request@es.net Wed Feb 10 07:01:59 1993 Date: Wed, 10 Feb 93 09:38:48 -0500 From: Jack Drescher (drescher@concert.net) To: ietf-announce-request@cnri.reston.va.us, rem-conf@es.net Subject: No REMCONF BOF at Columbus IETF Cc: mdavies@cnri.reston.va.us (MeganDavies-CNRI) Content-Length: 665 Status: RO X-Lines: 21 There is no separate REMCONF BOF scheduled for the Columbus IETF. The primary reason is that there are 11 hours of directly related work scheduled between the Audio/Video Transport Working Group and the Conferencing Control BOF. There are also an additional 2.5 hours of very relevant work scheduled in the IP Level Mechanisms for QOS and Real Time Services BOF, sometimes referred to as "Resource Management". We anticipate the scheduling of REMCONF BOFs at future IETFs on an as-needed basis. Work will continue on the development of the REMCONF architecture and it's public discussion via the IETF process. Jack Drescher MCNC Ari Ollikainen LLNL From rem-conf-request@es.net Fri Feb 12 17:05:31 1993 Date: Fri, 12 Feb 93 17:03:46 PST From: ari@es.net (Ari Ollikainen) To: rem-conf@es.net Subject: FWD:Internet Desktop Video Conference Demo from BBN Cc: dvtf@es.net, picwin-sales@bbn.com Content-Length: 2232 Status: RO X-Lines: 59 Found this in comp.multimedia... Odd that David Rich didn't think to send this to rem-conf, too. Or maybe someone thought that advertising would be in questionable taste? Begin forwarded message ------ From: drich@BBN.COM (David Rich) Newsgroups: comp.multimedia,comp.sys.sun.apps,ne.nearnet.tech,comp.protocols.tc p-ip Subject: Internet Desktop Video Conference Demo from BBN Keywords: Video Conferencing, IP, LAN, SPARC, desktop Date: 2 Feb 93 21:57:24 GMT Organization: Bolt Beranek and Newman Inc., Cambridge MA Lines: 33 NNTP-Posting-Host: bbn.com A public Internet demonstration of BBN's new PictureWindow(TM) video conferencing software is now available for Sun SPARCstation users who are connected to the Internet. The demonstration allows users to try a receive-only version of the software and sample the view from our server in Cambridge, Mass. PictureWindow is a software package that allows workstation users to hold video conferences over IP networks. PictureWindow's predecessor, DVC, was used to broadcast the July 1992 IETF conference. The tremendous interest in this software has prompted us to make this demonstration available to the public. All you need to run the demonstration is a Sun SPARCstation such as a 1, 1+, 2, IPC, IPX or SPARC 10. Additional information about the demo can be found in the README file. Demonstration, receive-only software is available through FTP: % ftp picwin.bbn.com < login "picwin"> ftp> binary ftp> get PWRX_README ftp> get pwrx_tarfile.Z ftp> quit % The PWRX_README file contains all the information you need to run the demonstration. For more information call 1-800-422-2359 or send electronic mail to picwin-sales@bbn.com. PictureWindow is a trademark of Bolt Beranek and Newman, Inc. End forwarded message ---------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ari Ollikainen ari@es.net National Energy Research Supercomputer Center ESnet (Energy Sciences Network) Lawrence Livermore National Laboratory 510-423-5962 FAX:510-423-8744 P.O. BOX 5509, MS L-561, Livermore, CA 94550 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf-request@es.net Sun Feb 14 23:08:52 1993 From: trannoy@berlioz.crs4.it (Antoine Trannoy) To: rem-conf@es.net Subject: 26th IETF Date: Sat, 13 Feb 93 16:48:05 +0100 Status: RO Content-Length: 171 X-Lines: 6 Will there be an audio multicast of the 26th IETF (Columbus, March 1993) on the Internet ? If yes, how can one get included in the multicast network ? Antoine Trannoy From rem-conf-request@es.net Mon Feb 15 11:19:43 1993 Date: 15 Feb 1993 14:08:01 -0500 (EST) From: "Gary C. Kessler, +1 802-879-3375" Subject: 18th LCN -- 2nd Announcement, Call for Papers To: atm@sun.com, cell-relay@mythos.ucs.indiana.edu, comp-protocols-tcp-ip@ucbvax.berkeley.edu, frftc@nsco.network.com, ietf@nri.reston.va.us, members@farnet.org, nren-discuss@psi.com, rem-conf@es.net, smdstc@nsco.network.com, wireless@tandem.com, isdn@list.prime.com X-Vms-To: @LCNLISTS Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Status: RO Content-Length: 2822 X-Lines: 75 ********** CALL FOR PAPERS ********** 18th Annual Conference on Local Computer Networks "The Conference on Practical Leading Edge Computer Networking" September 19-22, 1993, Minneapolis, Minnesota, USA ============================================================================ Sponsored by: IEEE Computer Society TC - Computer Communications ============================================================================ Theme: The emphasis on this year's conference is on practical experience using local computer networks. This unique approach simulates a workshop environment and allows for an effective interchange among users, researchers, & vendors. Some of the primary goals of the conference are to enable those involved in the local computer network field to share experiences, lessons learned, and prototype data and analysis. Because of these objectives, papers based on experience are especially solicited. The focus of the 18th LCN will be Multimedia and Video Communications. Papers that cover these areas are explicitly sought and will be given preference. Information for Authors: All authors must submit 5 full copies of the full technical paper by mail or delivery service. DO NOT SUBMIT COMPLETE PAPERS BY FAX. The first page must contain: title of the paper, author's names including affiliations, complete mailing address, telephone and FAX numbers, Internet or Bitnet address, and a 250 word (maximum) abstract (double-spaced) in English to Dr. Ken Ocheltree, Program Chair, at the address below. Sessions are being organized on: o Multi Media on the LCN o Multimedia Applications o Real-Time Video Applications o ATM o HPPI o Fiber Channel Networking o High Speed Networks o Gigabit Networks o Bandwidth Allocation o Isochronous Protocols o Compression Techniques o Error Control Techniques o Congestion Control o High Performance Protocols o Metropolitan Area Networks o LAN/MAN/WAN Integration o Internetworking o Standards o Network Management o Remote Monitoring o Reliability, Availability, & Maintainability (RAM) o Emerging Technologies o FDDI and FDDI-II o Security Send papers to: Dr. Kenneth Ocheltree, Program Chair Important Dates IBM T.J. Watson Research Center Submission: April 5, 1993 Mail Stop H4-A24 Acceptance: June 28, 1993 30 Saw Mill River Road Camera Copy: July 30, 1993 Hawthorne, NY 10532 USA +1 914-784-7903 (voice) Conference Summary +1 914-784-6201 (fax) - Tutorials keno@watson.ibm.com - Technical Paper Sessions - Panel Discussions From rem-conf-request@es.net Tue Feb 16 19:21:05 1993 Date: Tue, 16 Feb 93 22:11:47 EST From: hgs@research.att.com (Henning G. Schulzrinne) To: casner@isi.edu Subject: RTP addresses Cc: rem-conf@es.net Content-Length: 1382 Status: RO X-Lines: 26 For identification purposes, RTCP carries network addresses in a few places. Since it might be nice to use RTP to demo some of the current IPv7 proponents (or, just in case, if RTP is still around when one gets deployed), this limit seems artificial. (I'd also say that the use of IPv4 addresses within ftp seems to be now considered a bad engineering decision.) How about using the Unix sockaddr structure, with a 16-bit family value prepended to the address? On the other hand, since the value is not interpreted, just compared for equality, a simple length + value choice seems more appropriate. This, however, raises the issue as to whether two distinct entities might both choose the same length + value, say, an 8-byte SIP address and an 8-byte NSAP (unless we assume that these two would never be in use within the same Internet). Thus, both may be needed. This would allow to treat the address family as a part of the comparison. In summary, I see four choices: - fixed identifier (IPv4 + 2-byte within host) - sockaddr (16-bit address family identifier, then address) - length + value (treat like a string) - type + length (option within option...), 8 bits each; type is part of comparison It is not clear to me whether the AF_ values used in Unix are reasonably standardized, so that we can avoid having to assign yet another set of identifiers. Henning Schulzrinne From rem-conf-request@es.net Tue Feb 16 19:26:41 1993 From: Ron Frederick To: rem-conf@es.net Subject: New version of nv (2.5) -- source available Date: Tue, 16 Feb 1993 19:12:41 PST Content-Length: 1612 Status: RO X-Lines: 36 Hello everyone... I just put version 2.5 of 'nv', the network video tool, up for anonymous ftp on parcftp.xerox.com, in the /pub/net-research directory. This version is available in binary form for both the sun4 (SPARCstations, really) and the SGI (with transmit support for the Indigo with entry graphics and the starter video card). In addition, the source code for this version is available. The files are as follows: nvbin-2.5-sgi.tar.Z 826929 bytes nvbin-2.5-sun4.tar.Z 391153 bytes nvsrc-2.5.tar.Z 73125 bytes The following is from the CHANGES file about version 2.5: Added support for SGI machines, including transmit support for the SGI Indigo with entry graphics and the starter video card. Thanks go to Andrew Cherenson at SGI for the video capture routine for that board and help in doing the port. Added a new panel for "Conference Info", so that both transmit capable and receive only versions of nv can see and modify the conference address info and their local name. Added a set of buttons to change the size of the incoming video windows. In addition to the previously supported size, you can now make the window either half or double that size. Added a "-interface" command line option and X resource for multi-homed hosts, to allow you to specify which interface to use when transmitting. Added support for the X app-defaults environment variables such as XAPPLRESDIR, XFILESEARCHPATH, and XUSERFILESEARCHPATH. Worked around a TK bug which caused bogus error messages to appear on the SGI and might have also been responsible for the "transparent window" effect seen on the Suns. From rem-conf-request@es.net Wed Feb 17 01:59:33 1993 To: hgs@research.att.com (Henning G. Schulzrinne) Cc: rem-conf@es.net Subject: Re: RTP addresses Date: Wed, 17 Feb 93 09:32:44 +0000 From: Jon Crowcroft Content-Length: 681 Status: RO X-Lines: 19 why re-invent the wheel, or tie oneself to a particular API, in a protocol design i suggest you use NSAPs, they can always be munged to carry sip-addrs or pip-ids later... :-) i am also still concerned at the cut between presentaton coding and transport functionailty being made in RTP - although i thibk it has loads of the right functions, i think some are generic to "an" RTP, and some are to do with "some" media, which we dont know enough about to say which, yet... i also believe it MUST have some work below the current RTP in the way TCP has to support some form of combined admission and congestion control/avoidance (see paper upcoming from wakeman et al...) jon From rem-conf-request@es.net Wed Feb 17 01:59:33 1993 Cc: rem-conf@es.net Subject: Conference Control and RPC Date: Wed, 17 Feb 93 09:35:47 +0000 From: Jon Crowcroft Content-Length: 255 Status: RO X-Lines: 14 a draft paper is available on Conference Control and the use of RPC, for your comments ftp cs.ucl.ac.uk in darpa/conf-rpc.ps.Z binary mode transfer, its a (u**x) compressed, postscript file any trouble fetching or printing, let me know... cheers jon From rem-conf-request@es.net Thu Feb 18 00:57:35 1993 Posted-Date: Thu 18 Feb 93 00:28:25-PST Date: Thu 18 Feb 93 00:28:25-PST From: Stephen Casner Subject: Re: RTP addresses To: hgs@research.att.com Cc: rem-conf@es.net Mail-System-Version: Content-Length: 569 Status: RO X-Lines: 11 Henning, You raise a good point, but I don't think a UNIX sockaddr structure would be palatable. The most general option is type-length-value, but this starts to get rather long. I wonder if we should try to think more about shorter non-address identifiers that are unique within an appropriate space. That was the goal stated for the 32-bit "site ids" in the vat protocol, though clearly there are some problems in generating those identifiers appropriately to accommodate multiple sources per host and various kinds of mixing/replication. -- Steve ------- From rem-conf-request@es.net Thu Feb 18 01:46:26 1993 To: Stephen Casner Cc: hgs@research.att.com, rem-conf@es.net Subject: Re: RTP addresses Date: Thu, 18 Feb 93 10:25:26 +0100 From: Christian Huitema Content-Length: 380 Status: RO X-Lines: 9 >That was the goal stated for the 32-bit "site ids" >in the vat protocol, though clearly there are some problems in generating >those identifiers appropriately to accommodate multiple sources per host >and various kinds of mixing/replication. What about an Appletalk-like scheme of randomly choosing an id, then broadcast to the group and look for collisions? Christian Huitema From rem-conf-request@es.net Thu Feb 18 04:44:07 1993 From: "Erik E. Fair" (Your Friendly Postmaster) Subject: Re: RTP addresses To: Christian Huitema X-Return-Path: rem-conf-request@es.net Cc: Stephen Casner , hgs@research.att.com, rem-conf@es.net Date: Thu, 18 Feb 93 03:49:10 -0800 Sender: fair@apple.com Content-Length: 253 Status: RO X-Lines: 8 From: Christian Huitema What about an Appletalk-like scheme of randomly choosing an id, then broadcast to the group and look for collisions? Trust me: this doesn't scale. Erik E. Fair apple!fair fair@apple.com From rem-conf-request@es.net Thu Feb 18 06:03:19 1993 Date: Thu, 18 Feb 93 07:56:23 EST From: hgs@research.att.com (Henning G. Schulzrinne) To: Christian.Huitema@sophia.inria.fr Subject: Re: RTP addresses Cc: rem-conf@es.net Content-Length: 1168 Status: RO X-Lines: 27 Christian: Random allocation: As with multicast addresses, this doesn't work in networks which can be temporarily disjoint, something which seems to happen all too often in the current Internet. (Scenario: during a conference, a new member in Europe selects a new identifier, while the link across the pond is temporarily out of business, which just happens to be the same as that selected by another participant in the U.S.) Beyond disconnection, packet loss has to be dealt with, as well as the simultaneous-access problem. Clearly, the likelihood of choosing the same random number is probably close to winning the state lottery, but it does introduce subtle failure modes, in particular if application writers somehow don't get the random-ness part right (everybody calls random() with the same seed, in the belief that they'll get different numbers). None of these problems are insurmountable, but they quickly turn into a complicated retry-and-backoff algorithm just to get a unique ID. We know we have unique IDs already (as some form of network address or a part thereof), so creating an ID-mechanism just for this application seems overkill. Henning From rem-conf-request@es.net Fri Feb 19 02:05:48 1993 To: " (Henning G. Schulzrinne)" Cc: Christian.Huitema@sophia.inria.fr, rem-conf@es.net Subject: Re: RTP addresses Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam Phone: +31 20 5924098(work), +31 20 5924199 (fax), +31 20 6160335(home) X-Last-Band-Seen: Bad Livers, Macavity's Cat (Melkweg, 13-2) X-Mini-Review: folk+beer+sweat+fun Date: Fri, 19 Feb 1993 10:51:14 +0100 From: Jack Jansen Status: RO Content-Length: 869 X-Lines: 17 Actually, picking random unique IDs can work fine, *as long as your address space is large enough*. If you pick, say, a 64 bit address space the chance of collisions are so small that you might as well ignore them. After all, the chance that a udp packet will contain an undetected error is only 1 in 2**16, so even with large numbers of hosts picking unique ids the chances of collisions are orders of magnitudes smaller (Hmm, can't remember a reasonable estimate of n over k. I seem to remember, though, that with 2**16 hosts the chance of a collision is still smaller than 1 in 2**32). A similar scheme is used in the Amoeba distributed OS, with great success. -- Jack Jansen | If I can't dance I don't want to be part of Jack.Jansen@cwi.nl | your revolution -- Emma Goldman uunet!cwi.nl!jack G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl From deering@parc.xerox.com Sun Feb 21 22:24:22 1993 To: rem-conf@es.net, mbone@ISI.EDU Subject: Clinton & Gore on the MBone TODAY (Monday)! Date: Sun, 21 Feb 1993 22:19:40 PST Sender: Steve Deering From: Steve Deering Status: RO Content-Length: 914 X-Lines: 18 President Clinton and V.P. Gore will be visting Silicon Graphics, Inc. at about 9 am, California time, Monday Feb 22. Andy Charenson is going to try to transmit the proceedings over the MBone, using nevot (vat-compatible) and nv. Audio will be 64Kb PCM on the MBone Audio channel, and video will be nv format on the MBone Video channel, both advertised in sd. If you have to invoke the A/V programs manually (because you can't use sd for some reason), use the following parameters: audio: address 224.2.0.1, ttl 191 (using the default vat port, 3456) video: address 224.2.1.0, ttl 127 (using the default nv port, 4444) Supposedly, Clinton will give a 5-10 minute speech, and then will hold a 30 minute "town meeting" with selected SGI employees. Depending on when things actually get started, the event may end as late as 10:30 or 11:00. Expect a certain amount of SGI hype and White House hype. Steve From rem-conf-request@es.net Sun Feb 21 23:19:51 1993 To: rem-conf@es.net Subject: How does packet switched network respond to continuous media? Date: Mon, 22 Feb 93 08:16:43 +0100 From: Stein-Olav.Tonnessen@itek.norut.no X-Mts: smtp X-Charset: LATIN1 X-Char-Esc: 29 Status: RO Content-Length: 900 X-Lines: 19 We are doing research on how to transmit continuous media over packet switched networks. We are specially interested in results from measurements in real IP-networks. Has someone measured: - How high the packet-/bit error rate is? - How big the delay and jitter is? - Is it really a problem that packets arrives out of sequence? - How much buffer space, due to synchronisation, must the receiver have in different cases? For comparison with our own results, we would be grateful to get copies /reprints/hints on where to find research results covering this area. __________________________________________________________________________ Stein Olav Toennessen Phone: +47 83 80150, Fax: +478382420 NORUT Informasjonsteknologi AS NORUT-Gruppen AS N-9005 Tromsoe, Norway E-mail: stein-olav.tonnessen@itek.norut.no -------------------------------------------------------------------------- From rem-conf-request@es.net Sun Feb 21 23:20:08 1993 To: rem-conf@es.net, mbone@isi.edu Subject: Clinton & Gore on the MBone TODAY (Monday)! Date: Sun, 21 Feb 1993 22:19:40 PST Sender: Steve Deering From: Steve Deering Status: RO Content-Length: 914 X-Lines: 18 President Clinton and V.P. Gore will be visting Silicon Graphics, Inc. at about 9 am, California time, Monday Feb 22. Andy Charenson is going to try to transmit the proceedings over the MBone, using nevot (vat-compatible) and nv. Audio will be 64Kb PCM on the MBone Audio channel, and video will be nv format on the MBone Video channel, both advertised in sd. If you have to invoke the A/V programs manually (because you can't use sd for some reason), use the following parameters: audio: address 224.2.0.1, ttl 191 (using the default vat port, 3456) video: address 224.2.1.0, ttl 127 (using the default nv port, 4444) Supposedly, Clinton will give a 5-10 minute speech, and then will hold a 30 minute "town meeting" with selected SGI employees. Depending on when things actually get started, the event may end as late as 10:30 or 11:00. Expect a certain amount of SGI hype and White House hype. Steve From rem-conf-request@es.net Mon Feb 22 02:57:45 1993 From: Toerless Eckert Subject: Re: Clinton & Gore on the MBone TODAY (Monday)! To: Steve Deering Date: Mon, 22 Feb 93 11:36:47 MET Cc: rem-conf@es.net, mbone@ISI.EDU X-Mailer: ELM [version 2.3 PL11] Status: RO Content-Length: 1096 X-Lines: 20 > President Clinton and V.P. Gore will be visting Silicon Graphics, Inc. at > about 9 am, California time, Monday Feb 22. Andy Charenson is going to try > to transmit the proceedings over the MBone, using nevot (vat-compatible) and > nv. Audio will be 64Kb PCM on the MBone Audio channel, and video will be nv > format on the MBone Video channel, both advertised in sd. If you have to > invoke the A/V programs manually (because you can't use sd for some reason), > use the following parameters: > > audio: address 224.2.0.1, ttl 191 (using the default vat port, 3456) > video: address 224.2.1.0, ttl 127 (using the default nv port, 4444) > > Supposedly, Clinton will give a 5-10 minute speech, and then will hold a > 30 minute "town meeting" with selected SGI employees. Depending on when > things actually get started, the event may end as late as 10:30 or 11:00. > Expect a certain amount of SGI hype and White House hype. Would it be possible to broadcast audio by GSM using a ttl of 223 or greater ? As it stands a ttl of 191 doesn't enters europe (except for sweden). Toerless From rem-conf-request@es.net Mon Feb 22 07:02:48 1993 Date: Mon, 22 Feb 1993 09:35:55 -0500 To: rem-conf@es.net, mbone-na@isi.edu From: Scott_Brim@cornell.edu X-Sender: swb@132.236.199.25 Subject: Re: Clinton & Gore on the MBone TODAY (Monday)! Status: RO Content-Length: 561 X-Lines: 11 I'd like to suggest that people who are currently sending "casual" video not do so during the Clinton/Gore thing (at this instant that means Tom Easterday and Mitch Sukalski). The other day I asked for someone to help me demonstrate video -- I got five people sending at once, plus audio, and while the enthusiasm was inspiring the performance was bad enough that the demo seriously failed. Oh -- and GSM never sounds very good. Can we compromise on IDVI, or run two audio streams? Thanks ... Scott From rem-conf-request@es.net Mon Feb 22 07:21:47 1993 To: Scott_Brim@cornell.edu Cc: rem-conf@es.net, mbone-na@isi.edu Subject: Re: Clinton & Gore on the MBone TODAY (Monday)! Date: Mon, 22 Feb 93 09:56:20 -0500 From: "Thomas A. Easterday (+1 313 998 6285)" Status: RO Content-Length: 518 X-Lines: 11 >I'd like to suggest that people who are currently sending "casual" video >not do so during the Clinton/Gore thing (at this instant that means Tom >Easterday and Mitch Sukalski). The other day I asked for someone to help >me demonstrate video -- I got five people sending at once, plus audio, and >while the enthusiasm was inspiring the performance was bad enough that the >demo seriously failed. But what if my buddy Billy wants to talk to me....:-) Not to worry, I was planning on being a good citizen. Tom From rem-conf-request@es.net Mon Feb 22 07:59:56 1993 To: Toerless Eckert Cc: rem-conf@es.net, mbone@isi.edu Subject: Re: Clinton & Gore on the MBone TODAY (Monday)! Date: Mon, 22 Feb 1993 07:45:14 PST Sender: Steve Deering From: Steve Deering Status: RO Content-Length: 420 X-Lines: 11 > Would it be possible to broadcast audio by GSM using a ttl of 223 or > greater? As it stands a ttl of 191 doesn't enters europe (except for > sweden). Andy only got nevot working on the SGI machines last week in PCM mode; he hasn't tried GSM and doesn't want to use this occasion to start testing it. I will try to set up a PCM->GSM reflector at PARC, if I can figure out the necessary command-line magic. Steve From rem-conf-request@es.net Mon Feb 22 08:32:34 1993 Date: Mon, 22 Feb 93 11:07:45 EST From: JBB@watson.acc.virginia.edu Subject: Re: Clinton & Gore broadcast To: mbone@isi.edu, rem-conf@es.net Status: RO Content-Length: 1347 X-Lines: 29 On Mon, 22 Feb 1993 09:35:55 -0500 Scott Brim said: >I'd like to suggest that people who are currently sending "casual" video >not do so during the Clinton/Gore thing (at this instant that means Tom >Easterday and Mitch Sukalski). The other day I asked for someone to help >me demonstrate video -- I got five people sending at once, plus audio, and >while the enthusiasm was inspiring the performance was bad enough that the >demo seriously failed. > What's the solution to simultaneous broadcasts overloading the links. Our network managers become hysterical at the mere suggestion of our setting up a tunnel with SURNET, our nearest MBONE neighbor to which we're connected via a T1 link. The prevailing assumption is that even though we would be configured as a leaf, the mere fact that a tunnel has been established means that **all** multicast packets with sufficiently large TTLs will be sent down the link regardless of our conference par- ticipation. According to this view, multiple audio/video broadcasts will seriously degrade MBONE and non-MBONE traffic on the link and there is little the terminal node can do about it except abort the tunnel. Is this view correct, or are we missing something? Clarification will be appreciated. Thanks, Joseph Burch jbb@virginia.edu ITC-Carruthers Hall University of Virginia From rem-conf-request@es.net Mon Feb 22 08:34:14 1993 To: rem-conf@es.net Subject: Re: Clinton & Gore on the MBone TODAY (Monday)! Date: Mon, 22 Feb 93 08:16:50 -0800 From: Dave Hayes Status: RO Content-Length: 274 X-Lines: 9 Is this session being advertised on SD yet? ------ Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ...usc!elroy!dxh No one can make you feel inferior without your consent. From rem-conf-request@es.net Mon Feb 22 09:06:54 1993 To: Toerless Eckert Cc: rem-conf@es.net, mbone@isi.edu Subject: Re: Clinton & Gore on the MBone TODAY (Monday)! Date: Mon, 22 Feb 93 08:50:57 PST From: Van Jacobson Status: RO Content-Length: 142 X-Lines: 7 I've set up a GSM feed for the talk. It's on vat address: vat 224.2.11.11/4119/gsm/223 Let me know if there are problems with it. - Van From rem-conf-request@es.net Mon Feb 22 09:10:47 1993 From: Toerless Eckert Subject: Re: Clinton & Gore on the MBone TODAY (Monday)! To: Van Jacobson Date: Mon, 22 Feb 93 17:56:52 MET Cc: Toerless.Eckert@informatik.uni-erlangen.de, rem-conf@es.net, mbone@ISI.EDU X-Mailer: ELM [version 2.3 PL11] Status: RO Content-Length: 316 X-Lines: 12 > I've set up a GSM feed for the talk. It's on vat address: > > vat 224.2.11.11/4119/gsm/223 > > Let me know if there are problems with it. Did you set up an 'sd' announcement for that channel ? Would make it easy to check out if it's working, as right now there's no one else on the channel. Thanks Toerless From rem-conf-request@es.net Mon Feb 22 09:26:58 1993 Date: Mon, 22 Feb 93 12:07:40 -0500 From: Joe Ragland To: rem-conf@es.net Subject: Huh? Status: RO Content-Length: 572 X-Lines: 25 Clinton/Gore @ SGI = 192.48.168.1 whois 192.48.168 Centre National Universitaire Sud de Calcul (NET-CNUSC-DEMO) 950 rue de St-Priest B.P. 7229 F-34184 Montpellier CEDEX 4 France Netname: CNUSC-DEMO Netnumber: 192.48.168.0 Coordinator: Batllo, Marc (MB247) batllo@FRMOP11.BITNET +33 67 14 14 14 Record last updated on 27-Jan-93. To see this host record with registered users, repeat the command with a star ('*') before the name; or, use '%' to show JUST the registered users. Hmmm... Must be Mountain View, France? :-) --joe From rem-conf-request@es.net Mon Feb 22 09:42:15 1993 Date: Mon, 22 Feb 1993 12:24:09 -0500 (EST) From: Jeff Young To: mbone@isi.edu, rem-conf@es.net Subject: Re: Clinton & Gore broadcast Status: RO Content-Length: 206 X-Lines: 11 Could someone please confirm or deny that they are: Seeing this session advertised in sd? Hearing audio? Seeing video? At the NIH, we've got none of the above. ___________ jy young@heart.dcrt.nih.gov From rem-conf-request@es.net Mon Feb 22 09:49:52 1993 To: Toerless Eckert Cc: rem-conf@es.net, mbone@isi.edu Subject: Re: Clinton & Gore on the MBone TODAY (Monday)! Date: Mon, 22 Feb 93 09:30:10 PST From: Van Jacobson Status: RO Content-Length: 185 X-Lines: 5 Yes, there's an sd announcement for "Clinton/Gore GSM patch". You should see about 100 people listening but no one's talking since we're waiting for Clinton to show up & start. - Van From rem-conf-request@es.net Mon Feb 22 10:01:05 1993 From: Toerless Eckert Subject: again gsm channel To: Van Jacobson Date: Mon, 22 Feb 93 18:41:22 MET Cc: Toerless.Eckert@informatik.uni-erlangen.de, rem-conf@es.net, mbone@isi.edu X-Mailer: ELM [version 2.3 PL11] Status: RO Content-Length: 12509 X-Lines: 323 > Yes, there's an sd announcement for "Clinton/Gore GSM patch". > You should see about 100 people listening but no one's talking > since we're waiting for Clinton to show up & start. I don't see any announcement in sd and right now there's no one beside me visible on my 'vat 224.2.11.11/4119/gsm/223' !! I've appended what i can currently get of mbone by map-mbone. Maybe you can see, where the problem lies ? Toerless Multicast Router Connectivity: 18.58.0.150 (NINJA-TURTLE.MIT.EDU): 18.58.0.150: 192.52.71.21 (noc.near.net) [3/1] 35.1.1.56 (homeless.merit.edu): no response to query 36.8.0.243 (Greyhawk.Stanford.EDU): 36.8.0.243: 192.5.146.13 (snipe.psc.edu) [9/32] 36.56.0.150 (Atalante.Stanford.EDU) [2/32] 36.103.0.28 (Dragonlance.Stanford.EDU) [3/16] 36.56.0.150 (Atalante.Stanford.EDU): 36.56.0.150: 36.8.0.243 (Greyhawk.Stanford.EDU) [2/32] 36.103.0.28 (Dragonlance.Stanford.EDU) [2/32] 192.31.49.234 (Numenor.BARRNET.NET) [1/32] 36.103.0.28 (Dragonlance.Stanford.EDU): no response to query 128.2.209.9 (SPARKY.FAC.CS.CMU.EDU): 128.2.209.9: 192.5.146.13 (snipe.psc.edu) [3/32] 128.9.16.4 (mbone.isi.edu): 128.9.16.4: 128.9.160.153 (cub.isi.edu) [1/16] 128.125.51.22 (crater.usc.edu) [1/16] 128.49.17.180 (dolphin.nosc.mil) [1/64] 128.9.160.153 (cub.isi.edu): no response to query 128.42.42.23 (lampasas.is.rice.edu): 128.42.42.23: 128.241.0.84 (nisc.sesqui.net) [1/1] 128.49.17.180 (dolphin.nosc.mil): 128.49.17.180: 128.9.16.4 (mbone.isi.edu) [1/64] 198.17.47.39 (pravda.sdsc.edu) [3/16] 128.59.18.142: 128.59.18.142: 147.225.1.105 (mbone.ans.net) [3/32] 128.86.1.22 (biffa.ja.net): 128.86.1.22: 192.87.45.3 (reif.ripe.net) [3/32] 128.96.33.108 (cockatoo.bellcore.com): 128.96.33.108: 128.96.80.41 [3/32] 128.121.50.149 (bambi.jvnc.net) [3/32] 128.96.80.41: no response to query 128.112.64.75 (nascar.Princeton.EDU): no response to query 128.117.8.142 (mrbean.scd.ucar.edu): 128.117.8.142: 192.31.49.234 (Numenor.BARRNET.NET) [1/32] 128.241.0.84 (nisc.sesqui.net) [3/32] 128.121.50.149 (bambi.jvnc.net): 128.121.50.149: 128.112.64.75 (nascar.Princeton.EDU) [3/32] 138.15.102.37 [3/32] 128.96.33.108 (cockatoo.bellcore.com) [3/32] 192.35.82.97 (MBONE.CIT.CORNELL.EDU) [3/32] 192.5.146.13 (snipe.psc.edu) [3/32] 192.52.71.21 (noc.near.net) [3/32] 192.101.21.1 (ncnoc.concert.net) [3/32] 128.125.51.22 (crater.usc.edu): 128.125.51.22: 134.4.30.91 (charybdis.ipac.caltech.edu) [4/64] 128.125.53.225 (bigsur.usc.edu) [1/8] 137.78.160.8 (elxr-fddi.jpl.nasa.gov) [5/64] 128.9.16.4 (mbone.isi.edu) [1/16] 128.125.53.225 (bigsur.usc.edu): no response to query 128.128.16.93 (BELUGA.WHOI.EDU): 128.128.16.93: 128.128.100.60 (SLICK.WHOI.EDU) [3/2] 192.52.71.21 (noc.near.net) [3/32] 128.128.100.60 (SLICK.WHOI.EDU): 128.128.100.60: 128.128.16.93 (BELUGA.WHOI.EDU) [3/2] 128.130.34.20 (netman.kom.tuwien.ac.at): 128.130.34.20: 192.87.45.3 (reif.ripe.net) [1/32] 128.146.6.139 (fuji.acs.ohio-state.edu): 128.146.6.139: 128.146.116.8 (davros.acs.ohio-state.edu) [1/16] 128.146.110.50 (zaphod.mps.ohio-state.edu): 128.146.110.50: 128.146.116.8 (davros.acs.ohio-state.edu) [1/16] 128.146.112.93 (psycho.psy.ohio-state.edu): no response to query 128.146.116.8 (davros.acs.ohio-state.edu): 128.146.116.8: 128.146.112.93 (psycho.psy.ohio-state.edu) [1/16] 128.146.110.50 (zaphod.mps.ohio-state.edu) [2/16] 128.146.6.139 (fuji.acs.ohio-state.edu) [1/16] 192.131.22.4 (kauri.cic.net) [2/32] 131.187.1.136 (valhalla.oar.net) [3/64] 128.241.0.84 (nisc.sesqui.net): 128.241.0.84: 128.241.8.98 [1/192] 129.162.155.145 (technology.com) [2/32] 128.42.42.23 (lampasas.is.rice.edu) [1/1] 192.52.195.10 (norad.arc.nasa.gov) [3/32] 128.117.8.142 (mrbean.scd.ucar.edu) [3/32] 192.5.186.86 [3/64] 198.17.47.39 (pravda.sdsc.edu) [3/64] 128.241.8.98: 128.241.8.98: 128.241.0.84 (nisc.sesqui.net) [1/192] 129.127.80.49 (fleur.dvcr.adelaide.edu.au): no response to query 129.127.128.20 (odin.arch.adelaide.edu.au): 129.127.128.20: 129.127.80.49 (fleur.dvcr.adelaide.edu.au) [1/1] 192.43.207.12 (mullala.cs.mu.OZ.AU) [3/1] 129.162.155.145 (technology.com): no response to query 129.240.150.150 (white.uio.no): no response to query 130.237.212.6 (gaia.electrum.kth.se): 130.237.212.6: 192.16.123.222 [3/1] 130.237.212.148 (dumburken.electrum.kth.se) [1/1] 130.237.212.148 (dumburken.electrum.kth.se): 192.71.228.40: 192.71.228.41 [1/1] 192.71.228.13 [1/1] 130.237.212.148: 130.237.212.6 (gaia.electrum.kth.se) [1/1] 131.108.62.192 (dino-ss2.cisco.com): no response to query 131.123.2.37 (usenet.mcs.kent.edu): no response to query 131.187.1.136 (valhalla.oar.net): no response to query 131.188.34.64 (faui45f.informatik.uni-erlangen.de): 131.188.34.64: 192.87.45.3 (reif.ripe.net) [1/32] 132.236.200.16 (FALCON.CIT.CORNELL.EDU): no response to query 134.4.20.70 (brando.ipac.caltech.edu): no response to query 134.4.30.91 (charybdis.ipac.caltech.edu): 134.4.30.91: 134.4.20.70 (brando.ipac.caltech.edu) [1/1] 137.78.160.8 (elxr-fddi.jpl.nasa.gov) [1/16] 128.125.51.22 (crater.usc.edu) [4/64] 134.82.1.30 (castor.cs.bucknell.edu): no response to query 137.78.160.8 (elxr-fddi.jpl.nasa.gov): 137.78.160.8: 134.4.30.91 (charybdis.ipac.caltech.edu) [1/16] 128.125.51.22 (crater.usc.edu) [5/64] 192.52.195.10 (norad.arc.nasa.gov) [1/32] 138.15.102.37 (depot.ccrl.nj.nec.com): no response to query 138.96.24.78 (jerry.inria.fr): no response to query 139.88.27.12: no response to query 139.130.204.2 (cruskit.aarnet.edu.au): 139.130.204.2: 150.203.4.23 (netman.anu.edu.au) [1/32] 192.43.207.12 (mullala.cs.mu.OZ.AU) [1/32] 141.142.6.16 (bliga.ncsa.uiuc.edu): 141.142.6.16: 192.17.2.3 (mbone-uiuc.cic.net) [1/1] 141.142.221.67 (nvs.ncsa.uiuc.edu) [1/1] 141.142.22.19 (computer.ncsa.uiuc.edu) [1/1] 141.142.22.19 (computer.ncsa.uiuc.edu): 141.142.22.19: 141.142.6.16 (bliga.ncsa.uiuc.edu) [1/1] 141.142.221.67 (nvs.ncsa.uiuc.edu): no response to query 147.225.1.105 (mbone.ans.net): 147.225.1.105: 128.59.18.142 (minetta.cs.columbia.edu) [3/1] 35.1.1.56 (homeless.merit.edu) [3/1] 138.15.102.37 (depot.ccrl.nj.nec.com) [3/1] 192.35.82.97 (MBONE.CIT.CORNELL.EDU) [1/1] 150.203.4.23 (netman.anu.edu.au): 150.203.4.23: 150.203.20.12 (vesta.anu.edu.au) [2/64] 139.130.204.2 (cruskit.aarnet.edu.au) [1/64] 150.203.20.12 (vesta.anu.edu.au): 150.203.20.12: 150.203.4.23 (netman.anu.edu.au) [1/1] 156.24.1.1 (gateway.gtech.com): 156.24.1.1: 192.52.71.21 (noc.near.net) [3/192] 157.24.23.33 (sauron.it.lut.fi): 157.24.23.33: 192.16.123.222 (hydra.sics.se) [3/96] 192.5.146.13 (snipe.psc.edu): 192.5.146.13: 128.2.209.9 (SPARKY.FAC.CS.CMU.EDU) [3/32] 134.82.1.30 (castor.cs.bucknell.edu) [5/192] 128.121.50.149 (bambi.jvnc.net) [3/32] 192.131.22.4 (kauri.cic.net) [3/32] 192.52.195.10 (norad.arc.nasa.gov) [5/32] 36.8.0.243 (Greyhawk.Stanford.EDU) [9/32] 192.35.82.97 (MBONE.CIT.CORNELL.EDU) [1/1] 192.17.2.3 (mbone-uiuc.cic.net) [1/1] 198.17.47.39 (pravda.sdsc.edu) [1/1] 192.5.186.86: no response to query 192.9.9.7 (playground.Sun.COM): 192.9.9.7: 192.31.49.234 (Numenor.BARRNET.NET) [3/32] 192.16.123.222 (hydra.sics.se): 192.71.228.13: 192.71.228.40 [1/1] 192.16.123.222: 192.87.45.3 (reif.ripe.net) [3/192] 192.35.82.97 (MBONE.CIT.CORNELL.EDU) [8/32] 129.240.150.150 (white.uio.no) [3/32] 157.24.23.33 (sauron.it.lut.fi) [1/96] 130.237.212.6 (gaia.electrum.kth.se) [3/1] 192.16.184.180 (buizerd.cwi.nl): no response to query 192.16.199.52 (rurik.nikhef.nl): 192.16.199.52: 192.87.45.3 (reif.ripe.net) [1/1] 192.16.201.113 (schelvis.cwi.nl): 192.16.201.113: 192.87.45.3 (reif.ripe.net) [1/32] 192.16.184.180 (buizerd.cwi.nl) [1/1] 192.17.2.3 (mbone-uiuc.cic.net): 192.17.2.3: 141.142.6.16 (bliga.ncsa.uiuc.edu) [1/1] 192.5.146.13 (snipe.psc.edu) [1/1] 192.35.82.97 (MBONE.CIT.CORNELL.EDU) [1/1] 192.5.186.86 [3/32] 192.26.75.5: alias for 192.48.153.1 192.31.49.234 (Numenor.BARRNET.NET): 192.31.49.234: 36.56.0.150 (Atalante.Stanford.EDU) [1/32] 192.9.9.7 (playground.Sun.COM) [3/32] 192.48.153.1 (SGI.COM) [3/64] 131.108.62.192 (dino-ss2.cisco.com) [3/32] 192.43.207.12 (mullala.cs.mu.OZ.AU) [8/128] 128.117.8.142 (mrbean.scd.ucar.edu) [1/32] 198.17.47.39 (pravda.sdsc.edu) [1/1] 192.35.82.97 (MBONE.CIT.CORNELL.EDU): 192.35.82.97: 132.236.200.16 (FALCON.CIT.CORNELL.EDU) [1/32] 147.225.1.105 (mbone.ans.net) [1/64] 192.16.123.222 (hydra.sics.se) [8/64] 138.96.24.78 (jerry.inria.fr) [8/64] 192.52.71.21 (noc.near.net) [1/64] 128.121.50.149 (bambi.jvnc.net) [1/64] 192.5.146.13 (snipe.psc.edu) [1/16] 192.17.2.3 (mbone-uiuc.cic.net) [1/16] 198.17.47.39 (pravda.sdsc.edu) [1/16] 192.43.207.12 (mullala.cs.mu.OZ.AU): 192.43.207.12: 139.130.204.2 (cruskit.aarnet.edu.au) [1/32] 129.127.128.20 (odin.arch.adelaide.edu.au) [1/32] 192.31.49.234 (Numenor.BARRNET.NET) [8/96] 192.52.195.10 (norad.arc.nasa.gov) [2/64] 192.48.153.1 (SGI.COM): 192.26.75.5: 192.48.168.1 [1/1] 192.48.153.1: 192.31.49.234 (Numenor.BARRNET.NET) [3/64] 192.48.168.1: no response to query 192.52.71.21 (noc.near.net): 192.52.71.21: 156.24.1.1 (gateway.gtech.com) [3/192] 128.128.16.93 (BELUGA.WHOI.EDU) [3/32] 18.58.0.150 (NINJA-TURTLE.MIT.EDU) [3/32] 192.35.82.97 (MBONE.CIT.CORNELL.EDU) [3/32] 128.121.50.149 (bambi.jvnc.net) [3/32] 192.52.195.10 (norad.arc.nasa.gov): no response to query 192.71.228.13: alias for 192.16.123.222 192.71.228.40: alias for 130.237.212.148 192.71.228.41: no response to query 192.87.45.3 (reif.ripe.net): 192.87.45.3: 131.188.34.64 (faui45f.informatik.uni-erlangen.de) [1/32] 128.130.34.20 (netman.kom.tuwien.ac.at) [1/32] 192.16.199.52 (rurik.nikhef.nl) [1/16] 192.16.201.113 (schelvis.cwi.nl) [1/32] 128.86.1.22 (biffa.ja.net) [3/192] 192.16.123.222 (hydra.sics.se) [1/192] 192.88.195.10 (ns2.oar.net): 192.88.195.10: 139.88.27.12 (kestrel.lerc.nasa.gov) [2/32] 131.123.2.37 (usenet.mcs.kent.edu) [2/32] 131.187.1.136 (valhalla.oar.net) [2/32] 192.131.22.4 (kauri.cic.net) [2/32] 192.101.21.1 (ncnoc.concert.net): 192.101.21.1: 128.121.50.149 (bambi.jvnc.net) [3/32] 192.131.22.4 (kauri.cic.net): 192.131.22.4: 192.88.195.10 (ns2.oar.net) [3/32] 192.5.146.13 (snipe.psc.edu) [3/64] 192.5.186.86 [2/16] 128.146.116.8 (davros.acs.ohio-state.edu) [2/32] 198.17.47.39 (pravda.sdsc.edu): 198.17.47.39: 128.241.0.84 (nisc.sesqui.net) [1/1] 128.49.17.180 (dolphin.nosc.mil) [5/16] 192.31.49.234 (Numenor.BARRNET.NET) [1/1] 192.5.146.13 (snipe.psc.edu) [1/1] 192.35.82.97 (MBONE.CIT.CORNELL.EDU) [3/1] 192.52.195.10 (norad.arc.nasa.gov) [1/1] From rem-conf-request@es.net Mon Feb 22 10:54:07 1993 To: rem-conf@es.net Subject: Outages of the MBONE Date: Mon, 22 Feb 93 10:40:18 -0800 From: Dave Hayes Status: RO Content-Length: 391 X-Lines: 8 I notice many short-term outages of the audio traffic during the Clinton/Gore thing. What is that caused by, and is there anything that can be done about it? ------ Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ...usc!elroy!dxh Penitent (adj.) - 1. Someone who has been made incapable of enjoyment. From rem-conf-request@es.net Mon Feb 22 11:32:20 1993 To: Van Jacobson Cc: Toerless Eckert , rem-conf@es.net, mbone@isi.edu Subject: Re: Clinton & Gore on the MBone TODAY (Monday)! From: Tony Bates X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Date: Mon, 22 Feb 93 19:54:03 +0100 Sender: tony@ripe.net Status: RO Content-Length: 603 X-Lines: 15 Van Jacobson writes: * Yes, there's an sd announcement for "Clinton/Gore GSM patch". * You should see about 100 people listening but no one's talking * since we're waiting for Clinton to show up & start. * * - Van I know this may be too late now but we (here in Europe) are not seeing the sd or the GSM mixing here. THe 192 TTL on the US-SE link and hence beyond should still give us the "Clinton/Gore GSM patch" 223 ttl should it ? I checked the mrouted and the sgi routes and lbl and the metrics are still within reach so am not sure why we are not seeing it ? ? -Tony From rem-conf-request@es.net Mon Feb 22 11:38:48 1993 To: Tony Bates Cc: Toerless Eckert , rem-conf@es.net, mbone@isi.edu Subject: Re: Clinton & Gore on the MBone TODAY (Monday)! Date: Mon, 22 Feb 93 11:30:20 PST From: Van Jacobson Status: RO Content-Length: 654 X-Lines: 16 Tony & Toorless, I think the problem is asymmetric metric on some European tunnel. The sd announcement & the vat audio were going out with ttl 223 -- I could see them anywhere in the US where I have an account. I could also see both of you in the GSM vat conference: eckert@faui45r.informatik.uni-erlangen.de (131.188.34.54/128.3.112.25) Tony Bates, RIPE NCC, Amsterdam (192.87.45.6/128.3.112.25) and I heard Toerless when he was asking if anyone could hear him (it was clear he couldn't hear the replies). So, something in the path from the US to you is filtering out ttl <= 223 while the path from you to the US is passing ttl <= 223. - Van From rem-conf-request@es.net Mon Feb 22 12:18:48 1993 From: Toerless Eckert Subject: Re: Clinton & Gore on the MBone TODAY (Monday)! To: Van Jacobson Date: Mon, 22 Feb 93 21:03:57 MET Cc: Tony.Bates@ripe.net, Toerless.Eckert@informatik.uni-erlangen.de, rem-conf@es.net, mbone@ISI.EDU Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.3 PL11] Status: RO Content-Length: 795 X-Lines: 19 > Tony & Toorless, > > I think the problem is asymmetric metric on some European tunnel. > The sd announcement & the vat audio were going out with ttl 223 -- > I could see them anywhere in the US where I have an account. I > could also see both of you in the GSM vat conference: > > eckert@faui45r.informatik.uni-erlangen.de (131.188.34.54/128.3.112.25) > Tony Bates, RIPE NCC, Amsterdam (192.87.45.6/128.3.112.25) > > and I heard Toerless when he was asking if anyone could hear him > (it was clear he couldn't hear the replies). So, something in the > path from the US to you is filtering out ttl <= 223 while the path > from you to the US is passing ttl <= 223. Please tell me, which router is the nearest to SGI's ? I would like to trace the path with the mrouted tool.. Toerless From rem-conf-request@es.net Mon Feb 22 14:20:40 1993 To: rem-conf@es.net Subject: Interop - Any plans? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Feb 1993 17:15:04 +22311949 From: Valdis Kletnieks Status: RO Content-Length: 164 X-Lines: 7 Is anybody planning to demo cross-Internet conferencing at Interop? If so, when and where? -- Valdis Kletnieks Computer Systems Engineer Virginia Tech From rem-conf-request@es.net Tue Feb 23 00:12:12 1993 To: Ron Frederick Cc: rem-conf@es.net Subject: Re: Clinton & Gore on the MBone Yesterday. Date: Tue, 23 Feb 93 09:07:38 +0100 From: Christian Huitema Status: RO Content-Length: 621 X-Lines: 12 We were receiving the sound + video OK here yesterday evening. I noticed however a strange visual effect -- the images appeared "shimmering". Small spots would rapidly change luminancy, without much correlation with the local context. While this was quite nice from a distance, maybe a new form of conceptual art, it did not enhance the readibility of the scenes. I presume that this is due to packet losses -- video and audio were sent at a rather large data rate. But this particular form of "non correlation" between errors probably also results from the organization of the data stream. Any idea? Christian Huitema From rem-conf-request@es.net Tue Feb 23 01:11:04 1993 To: Christian Huitema Cc: rem-conf@es.net Subject: Re: Clinton & Gore on the MBone Yesterday. Date: Tue, 23 Feb 93 08:41:59 +0000 From: Jon Crowcroft Status: RO Content-Length: 176 X-Lines: 7 if anyone cares, part of clinton/gore california dreamboating was televised in the uk, but the Internet _wasn't mentioned: but then we live in a cultural backwater:-( jon From rem-conf-request@es.net Tue Feb 23 04:25:22 1993 To: Christian Huitema Cc: rem-conf@es.net, deering@parc.xerox.com Subject: Re: Clinton & Gore on the MBone Yesterday. Date: Tue, 23 Feb 1993 03:57:10 PST Sender: Steve Deering From: Steve Deering Status: RO Content-Length: 587 X-Lines: 12 > We were receiving the sound + video OK here yesterday evening. I noticed > however a strange visual effect -- the images appeared "shimmering". Small > spots would rapidly change luminancy, without much correlation with the local > context. While this was quite nice from a distance, maybe a new form of > conceptual art, it did not enhance the readibility of the scenes. If you are referring to the effect I think you are, it was caused by photographers' flashes at the event site. I saw the event later on real TV, and there was quite a lot of flash photography happening. Steve From rem-conf-request@es.net Tue Feb 23 04:30:45 1993 Date: Tue, 23 Feb 93 07:18:10 -0500 From: Joe Ragland To: Christian.Huitema@sophia.inria.fr, frederic@parc.xerox.com Subject: Re: Clinton & Gore on the MBone Yesterday. Cc: rem-conf@es.net Status: RO Content-Length: 735 X-Lines: 17 > We were receiving the sound + video OK here yesterday evening. I noticed > however a strange visual effect -- the images appeared "shimmering". Small > spots would rapidly change luminancy, without much correlation with the local > context. While this was quite nice from a distance, maybe a new form of > conceptual art, it did not enhance the readibility of the scenes. > > I presume that this is due to packet losses -- video and audio were sent at a > rather large data rate. But this particular form of "non correlation" between > errors probably also results from the organization of the data stream. Any > idea? Christian, I think what you are referring to was the result of flash from still photographer's cameras. --joe From rem-conf-request@es.net Tue Feb 23 05:30:29 1993 To: Joe Ragland Cc: rem-conf@es.net Subject: Re: Clinton & Gore on the MBone Yesterday. Date: Tue, 23 Feb 93 14:03:59 +0100 From: Christian Huitema Status: RO Content-Length: 123 X-Lines: 4 Yes, photographers' flashes could do that. We could not recognize them as such, but that would explain. Christian Huitema From rem-conf-request@es.net Tue Feb 23 10:18:22 1993 Posted-Date: Tue 23 Feb 93 10:08:43-PST Date: Tue 23 Feb 93 10:08:43-PST From: Stephen Casner Subject: Re: Clinton & Gore on the MBone Yesterday. To: deering@parc.xerox.com, Christian.Huitema@sophia.inria.fr Cc: rem-conf@es.net Mail-System-Version: Status: RO Content-Length: 459 X-Lines: 10 > If you are referring to the effect I think you are, it was caused by > photographers' flashes at the event site. I saw the event later on real > TV, and there was quite a lot of flash photography happening. It is likely that the flashes caused some effects, but as I recall there were times when several rows of blocks were painted with white at the top and dark (normal color) at the bottom of each block. How would that happen? -- Steve ------- From rem-conf-request@es.net Tue Feb 23 11:01:04 1993 From: avalon@coombs.anu.edu.au (Darren Reed) Subject: Re: RTP addresses To: hgs@research.att.com (Henning G. Schulzrinne) Date: Wed, 24 Feb 93 5:44:04 EST Cc: Christian.Huitema@sophia.inria.fr, rem-conf@es.net Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Status: RO Content-Length: 741 X-Lines: 15 In some email I received from Henning G. Schulzrinne, Sie wrote: [...] > None of these problems are insurmountable, but they quickly turn into > a complicated retry-and-backoff algorithm just to get a unique ID. We > know we have unique IDs already (as some form of network address or a > part thereof), so creating an ID-mechanism just for this application > seems overkill. Following this idea, wouldn't it be sensible to use the IP# (or endpoint ID for those who are thinking beyond IPv4) which creates the session in with the ID ? Using that along with some other value which is gauranteed to be unique for the duration of the conference might be of use. This also gives you a bonus by telling you where a session originated. Darren From rem-conf-request@es.net Tue Feb 23 11:09:27 1993 To: rem-conf@es.net Subject: Re: Clinton & Gore on the MBone Yesterday. Date: Tue, 23 Feb 93 11:00:46 -0800 From: Dave Hayes Status: RO Content-Length: 319 X-Lines: 8 Did anyone happen to record the event, or get a transcription? ------ Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ...usc!elroy!dxh Nobody wants constructive criticism. It's all we can do to put up with constructive praise. From rem-conf-request@es.net Tue Feb 23 12:16:25 1993 Date: Tue, 23 Feb 1993 12:00:45 PST Sender: Ron Frederick From: Ron Frederick To: Stephen Casner , arc@sgi.com Subject: Re: Clinton & Gore on the MBone Yesterday. Cc: rem-conf@es.net Status: RO Content-Length: 1048 X-Lines: 21 >> If you are referring to the effect I think you are, it was caused by >> photographers' flashes at the event site. I saw the event later on real >> TV, and there was quite a lot of flash photography happening. > >It is likely that the flashes caused some effects, but as I recall >there were times when several rows of blocks were painted with white >at the top and dark (normal color) at the bottom of each block. How >would that happen? I noticed this same behavior where it would only affect portions of the blocks. Since we haven't ever seen anything like this before on the SGI, I'm still tempted to say it was caused by the flashes -- but I don't have a good model for how that might happen. I could certainly believe one row of blocks in a given frame appearing half bright, if the flash began or ended in the middle of a capture. Did anyone see definite evidence that the shimmerring hit multiple blocks on different rows in the same frame? I can't really remember myself whether I saw that. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Tue Feb 23 13:00:24 1993 To: rem-conf@es.net Subject: Re: Clinton & Gore on the MBone Yesterday. Date: Tue, 23 Feb 93 12:54:45 -0800 From: berc@src.dec.com X-Mts: smtp Status: RO Content-Length: 206 X-Lines: 4 We watched it here via J-Video and saw lots of flashes. I thought that one roll of film per photographer would be enough, but seemed to keep their motor drives running through most of the presentation. From rem-conf-request@es.net Tue Feb 23 13:02:56 1993 Date: Tue, 23 Feb 93 15:55:23 EST From: Frank T Solensky To: CASNER@isi.edu, arc@sgi.com, frederic@parc.xerox.com Subject: Flashing Clinton (was Re: Clinton & Gore on the MBone Yesterday.) Cc: rem-conf@es.net Status: RO Content-Length: 669 X-Lines: 11 >I noticed this same behavior where it would only affect portions of the >blocks. Since we haven't ever seen anything like this before on the SGI, >I'm still tempted to say it was caused by the flashes -- but I don't have a >good model for how that might happen. I could certainly believe one row >of blocks in a given frame appearing half bright, if the flash began or >ended in the middle of a capture. Did anyone see definite evidence that >the shimmerring hit multiple blocks on different rows in the same frame? FWIW: the electronic flashes that many photojournalists use have a flash synch speed of 1/250th sec, or 4 msecs. That would be about 8 video frames. From rem-conf-request@es.net Tue Feb 23 13:36:13 1993 Date: Tue, 23 Feb 1993 13:23:41 PST Sender: Ron Frederick From: Ron Frederick To: CASNER@isi.edu, arc@sgi.com, Frank T Solensky Subject: Re: Flashing Clinton (was Re: Clinton & Gore on the MBone Yesterday.) Cc: rem-conf@es.net Status: RO Content-Length: 583 X-Lines: 16 Frank Solensky writes: > FWIW: the electronic flashes that many photojournalists use have a > flash synch speed of 1/250th sec, or 4 msecs. That would be about 8 video > frames. Actually, 4 msec is about 1/8th of a video frame, which would match with the notion that it might only affect a band of the picture. At the edges of the band, the half-bright blocks would appear. In between, it should _try_ to transmit the whole area, but it wouldn't always have enough room in the current frame to do so... Thanks for the data point, Frank. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Tue Feb 23 14:00:14 1993 From: booloo@framsparc.ocf.llnl.gov (Mark Boolootian) Subject: Re: Clinton & Gore on the MBone Yesterday. To: rem-conf@es.net Date: Tue, 23 Feb 1993 13:50:44 -0800 (PST) X-Mailer: ELM [version 2.4 PL17] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 397 Status: RO X-Lines: 12 Referring to the Clinton/Gore visit to SGI yesterday, Dave Hayes writes: > >Did anyone happen to record the event, or get a transcription? > The Internet Society is providing gopher access for White House Press Releases. This includes a complete transcript of yesterday's SGI meeting. mb -- Mark Boolootian booloo@llnl.gov +1 510 423 1948 Disclaimer: booloo speaks for booloo and no other. From rem-conf-request@es.net Tue Feb 23 14:13:02 1993 From: Andrew Heybey To: Frank T Solensky Cc: CASNER@isi.edu, arc@sgi.com, frederic@parc.xerox.com, rem-conf@es.net Subject: Re: Flashing Clinton (was Re: Clinton & Gore on the MBone Yesterday.) Date: Tue, 23 Feb 93 17:00:06 -0500 Sender: ath@anise.lcs.mit.edu X-Mts: smtp Status: RO Content-Length: 921 X-Lines: 21 # Date: Tue, 23 Feb 93 15:55:23 EST # From: Frank T Solensky # To: CASNER@isi.edu, arc@sgi.com, frederic@parc.xerox.com # Subject: Flashing Clinton (was Re: Clinton & Gore on the MBone Yesterday.) # Cc: rem-conf@es.net # # FWIW: the electronic flashes that many photojournalists use have a flash # synch speed of 1/250th sec, or 4 msecs. That would be about 8 video frames. # 1/250th of a second is the fastest speed at which the *shutter* in most current SLR cameras is open over the entire frame at once. The flash itself produces an extremely fast pulse of light. (For example, Doc Edgarton used strobes to stop bullets in flight, etc.) Faster shutter speeds are produced by moving a slit across the frame. If you use a flash with a faster shutter speed, you get an almost-black frame with a strip of the picture across it. We now return you to remote conferencing discussions. andrew From rem-conf-request@es.net Tue Feb 23 14:27:04 1993 Date: Tue, 23 Feb 1993 14:10:06 -0800 To: CASNER@isi.edu, arc@sgi.com, Frank T Solensky , Ron Frederick From: brian@mail.barrnet.net Subject: Re: Flashing Clinton (was Re: Clinton & Gore on the MBone Yesterday.) Cc: rem-conf@es.net Status: RO Content-Length: 1315 X-Lines: 28 >Frank Solensky writes: > >> FWIW: the electronic flashes that many photojournalists use have a >> flash synch speed of 1/250th sec, or 4 msecs. That would be about 8 video >> frames. > >Actually, 4 msec is about 1/8th of a video frame, which would match with >the notion that it might only affect a band of the picture. At the edges of >the band, the half-bright blocks would appear. In between, it should _try_ >to transmit the whole area, but it wouldn't always have enough room in >the current frame to do so... Xenon-type photoflash units typically have a flash duration of .1ms to 1ms. Most modern flash units use a sensor to "turn off" the flash when the exposure is complete thus saving energy for the next flash. This can and does produce a very short duration flash. The 1/250 sec synchronization is simply to ensure that the shutter is completely open before the flash is triggered and that the shutter is still completely open when the flash later extinguishes. Now back to our regularly scheduled program. Brian Lloyd 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 brian@mail.barrnet.net (916) 676-3442 - fax (415) 725-1392 (916) 676-1147 - voice From rem-conf-request@es.net Tue Feb 23 15:48:23 1993 Date: Tue, 23 Feb 93 15:39:22 -0800 From: touch@ISI.EDU Posted-Date: Tue, 23 Feb 93 15:39:22 -0800 Original-Received: by NeXT.Mailer (1.87.1) Pp-Warning: Illegal Received field on preceding line Original-Received: by NeXT Mailer (1.87.1) Pp-Warning: Illegal Received field on preceding line To: Andrew Heybey Subject: Re: Flashing Clinton (was Re: Clinton & Gore on the MBone Yesterday.) Cc: Frank T Solensky , CASNER@ISI.EDU, arc@sgi.com, frederic@parc.xerox.com, rem-conf@es.net Status: RO Content-Length: 2366 X-Lines: 56 > Begin forwarded message: > From: Andrew Heybey > To: Frank T Solensky > Cc: CASNER@ISI.EDU, arc@sgi.com, frederic@parc.xerox.com, rem-conf@es.net > Subject: Re: Flashing Clinton (was Re: Clinton & Gore on the...) > Date: Tue, 23 Feb 93 17:00:06 -0500 > Sender: ath@anise.lcs.mit.edu > # Date: Tue, 23 Feb 93 15:55:23 EST > # From: Frank T Solensky > # To: CASNER@isi.edu, arc@sgi.com, frederic@parc.xerox.com > # Subject: Flashing Clinton (was Re: Clinton & Gore on the ...) > # Cc: rem-conf@es.net > # > # FWIW: the electronic flashes that many photojournalists use have a flash > # synch speed of 1/250th sec, or 4 msecs. That would be about 8 video frames. > # > 1/250th of a second is the fastest speed at which the *shutter* in most > current SLR cameras is open over the entire frame at once. The flash > itself produces an extremely fast pulse of light. (For example, Doc > Edgarton used strobes to stop bullets in flight, etc.) Faster shutter > speeds are produced by moving a slit across the frame. If you use a > flash with a faster shutter speed, you get an almost-black frame with > a strip of the picture across it. The "slit" doesn't exist - it's an artifact of a particular (and common) SLR mechanism of shuttering using two 'chasing shades'. An SLR shutter works by having two 'shades' - one stored on the right, one stored on the left. When you are ready to take a picture (after film advance), Shutter A is open and B is closed. Taking a picture involves opening shutter B and then closing shutter A. The shutters have some finite time to open or close (usually the same). 1/250 sec is the shutter speed at which there is an interval where both A and B are completely open (this used to be 1/60 sec on older cameras). At highter shutter speeds, B is still opening when A starts closing, in effect, A's edge "chases" B's edge across the film, at a width less than that of the complete frame. (A "still" photograph at these speeds becomes a space-time diagram from one side to the other, resulting in some interesting pictures that could not have existed at a single point in time). The flash records this chasing phenomenon as a stripe, recording the time when the two edges were in transit and the flash occurred. Joe Touch touch@isi.edu From rem-conf-request@es.net Tue Feb 23 16:53:44 1993 To: Van Jacobson Cc: rem-conf@es.net Subject: Peak meters? Date: Tue, 23 Feb 93 16:47:32 -0800 From: Dave Hayes Status: RO Content-Length: 819 X-Lines: 15 Can you offer a mode for those vat meters so that they'd be PEAK indicators and not level (kind of like professional meters)? You know, store the peak value over the last N seconds and display that? I offer this only as a "luxury". ------ Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ...usc!elroy!dxh Two men came before Nasrudin. The first said, "He bit my ear -- I demand compensation." The other said, "He bit it himself." Nasrudin went to his chambers, spent an hour trying to bite his own ear, and succeeded only in bruising his forehead. Returning, Nasrudin said, "Examine the man whose ear was bitten. If his forehead is bruised, the case is dismissed. Otherwise, the other man must pay three silver pieces." From rem-conf-request@es.net Tue Feb 23 23:25:39 1993 To: Joe Ragland Cc: rem-conf@es.net Subject: Re: Clinton & Gore on the MBone Yesterday. Date: Tue, 23 Feb 1993 22:50:08 -0800 From: Thomas Maslen Content-Length: 235 Status: RO X-Lines: 9 > I think what you are referring to was the result of flash from still > photographer's cameras. Oh. You mean it wasn't because young Bill was scintillating? > --joe Thomas Maslen maslen@eng.sun.com My opinions, not Sun(Soft)'s From rem-conf-request@es.net Wed Feb 24 08:41:37 1993 Date: 24 Feb 1993 11:43:04 U From: Barbara Aris Subject: subscribe rem-conf Barbara To: Rem Conf Status: RO Content-Length: 36 X-Lines: 4 subscribe rem-conf Barbara Weir From rem-conf-request@es.net Wed Feb 24 12:35:47 1993 Date: Wed, 24 Feb 1993 14:06:17 -0600 From: dab@berserkly.cray.com (David A. Borman) To: ath@lcs.mit.edu, touch@ISI.EDU Subject: Re: Flashing Clinton (was Re: Clinton & Gore on the MBone Yesterday.) Cc: arc@sgi.com, CASNER@ISI.EDU, frederic@parc.xerox.com, rem-conf@es.net, solensky@andr.ub.com Status: RO Content-Length: 1508 X-Lines: 29 Note: This follow-on message really has nothing to do with remote conferencing, but I can't resist... ;-) > > 1/250th of a second is the fastest speed at which the *shutter* in most > > current SLR cameras is open over the entire frame at once. The flash > > itself produces an extremely fast pulse of light. (For example, Doc > > Edgarton used strobes to stop bullets in flight, etc.) Faster shutter > > speeds are produced by moving a slit across the frame. If you use a > > flash with a faster shutter speed, you get an almost-black frame with > > a strip of the picture across it. > > The "slit" doesn't exist - it's an artifact of a particular (and common) SLR > mechanism of shuttering using two 'chasing shades'. > > An SLR shutter works by having two 'shades' - one stored on the right, one > stored on the left. When you are ready to take a picture (after film > advance), Shutter A is open and B is closed. Taking a picture involves > opening shutter B and then closing shutter A. Well, now, that depends on your camera. My Graflex has a shutter curtian that most definitly has a "slit", actually it has about 5 slits of different widths. That combined with various tension settings on the shutter curtian gives me a range of shutter speeds between 1/10th and 1/1000th of a second. Granted, my camera isn't a 35mm camera (it takes 4"x5" negatives), is 40-50 years old and doesn't use a flash, but it is an SLR camera, and it does have real slits. -David Borman, dab@cray.com From rem-conf-request@es.net Wed Feb 24 13:23:47 1993 To: rem-conf@es.net Subject: REPOST: Announcement of AF (AF2R2) source kit for distributed audio. Date: Wed, 24 Feb 93 16:16:06 -0500 From: Jim Gettys X-Mts: smtp Status: RO Content-Length: 7509 X-Lines: 207 While this has been posted to quite a few Usenet newsgroups, some folks on this mailing list may avoid netnoise; for those who have seen the annoucement, my apologies. Note that AudioFile currently runs on MIPS/Ultrix, Alpha/OSF, and Sparc under SunOS, and supports 8KHZ audio, Hifi, and telephone interfaces if appropriate hardware is present. Enjoy... - Jim Gettys (on behalf of the AF gang of Levergood, Stewart, Treese, Gettys, and Payne...). AudioFile Version 2, Release 2 README Introduction ------------- The AudioFile System (AF) is a device-independent network-transparent audio server. With AudioFile, multiple audio applications can run simultaneously, sharing access to the actual audio hardware. Network transparency means that application programs can run on machines scattered throughout the network. Because AF permits applications to be device-independent, applications need not be rewritten to work with new audio hardware. AudioFile does for sound what the X Window System does for text and graphics. Development of AudioFile began in 1989 at Digital Equipment Corporation's Cambridge Research Laboratory, but it builds on ideas from earlier work. We originally envisioned AudioFile as a server to support all the capabilities of the CRL "LoFi" audio hardware running on the DECstation 5000 workstation, but we soon began adding support for a variety of other platforms and audio hardware. This distribution of AudioFile includes device drivers for several audio devices, server code for a number of platforms, a programming API and library, out-of-the-box core applications, and a number of "contributed" applications. The key difference between the core and contributed applications is that the many of the contrib clients also depend on the TCL/Tk graphics toolkits distributed by the University of California. (The AudioFile distribution does not include TCL/Tk, but we tell you where to get it.) With AudioFile, it is easy to incorporate audio into applications. Simple "play" and "record" applications are included, or you can write your own using the AudioFile API and client library. AudioFile allows applications to generate and process audio in real-time but it also permits more leisurely applications. AudioFile is quite resistant to the vagaries of scheduling and operating systems that can make handling audio difficult. We have successfully used AudioFile for both trivial applications (audio BIFF) and complex applications (real-time teleconferencing, speech synthesis and recognition.) AudioFile may not be appropriate for all purposes, but we have found it to be a versatile and effective tool. We believe that AudioFile is highly portable, and that it should be straightforward to add additional support for other systems equipped with audio hardware. AudioFile is distributed in source form, with a copyright allowing unrestricted use for any purpose except sale (see the Copyright notice). We would like to encourage other organizations to add support to AudioFile for additional platforms, operating systems, and devices, and to contribute additional applications. We have set up a mailing list for discussions of AudioFile: af@crl.dec.com send mail to af-request@crl.dec.com to be added to this list. AudioFile Server ----------------- This distribution of AudioFile includes server support for Digital RISC systems running Ultrix, Digital Alpha AXP systems running OSF/1, and Sun Microsystems SPARCstations running SunOS. The servers support audio hardware ranging from the built-in CODEC audio on SPARCstations and Personal DECstations to 48 KHz stereo audio using the DECaudio TURBOchannel module. In addition, server support is present for telephone access devices such as DECaudio. AudioFile API -------------- The distribution includes C language bindings to the protocol that make it easy to write distributed audio applications. AudioFile Clients ------------------ This distribution includes a number of core applications for recording, playback, telephone control, device control, and access control. AudioFile "Contrib" Clients ---------------------------- The distribution includes a number of contributed applications including an audio file browser, an FFT spectrogram display, and multicast network audio service. Kit Location ------------- The kit is located at ftp site crl.dec.com (Internet 192.58.206.2) in /pub/DEC/AF. The kit is contained in a compressed tar file named AF2R2.tar.Z. Use anonymous ftp to retrieve the file, % ftp crl.dec.com ... ftp> cd /pub/DEC/AF ftp> binary ftp> get AF2R2.tar.Z The kit is shipped as a compressed tar file. To unpack the kit, % cd % zcat AF2R2.tar.Z | tar xpBf - We also provide a sample kit of Hi-Fi sound bites for use with DECaudio. If you have a DECaudio, you might considering retrieving AF2R2-other.tar.Z and unpack this kit in the same manner as described above. Other files available in this same directory are the release notes, copyright notice, and this README file. Roadmap -------- Several directories will be created in your local audio root directory. The "AF" sub-tree contains the source code for the AudioFile server, the AudioFile client library, and several AudioFile client programs. The "devices" sub-tree contain the device specific code not related to the AF system. For example, the LoFi device library, LoFi device driver, and test programs are included here. Finally, "sound_files" contains several sound bites you can use while verifying the kit installation. The kit requires approximately 6 Megabytes and an additional 8 Megabytes for building and installing the release. The HiFi sound files require another 4 Megabytes approximately. Documents ---------- You should read the following documents prior to installing this software. o AF Release Notes - /AF/RELNOTES.{txt,PS} o Copyrights information - /COPYRIGHTS Suggested Sequence ------------------- o Retrieve the software package and create a local audio hierarchy. o Read the documents mentioned above. o Build the AudioFile release (after unpacking the kit.) % cd Customize the build environment for your local site according to the information contained in the release notes. Follow the directions there in order to build this release. Typing, % make Help in the directory can be used as a reminder of the steps in the build process. You might want to save the output of the build and install session in order to identify problems should any occur. o If you are using LoFi/DECaudio or the native audio on DECstations or Alpha AXP workstations for the first time, see the instructions in one of these directories for information about the hardware and device drivers. For the native DECstation audio device, /devices/maxine/driver/mips.src/bba.4 man page For the native Alpha AXP workstation audio device, /devices/axp/driver/README For LoFi/DECaudio, On Ultrix/RISC (MIPS): /devices/lofi/driver/mips.src/lofi.4 man page On DEC OSF/1 Alpha: /devices/lofi/driver/alpha.src/lofi.7 man page /devices/lofi/driver/alpha.src/README o Test the AudioFile server and clients. o Have fun! Copyrights ----------- See the file /COPYRIGHTS for the full copyright and permission notice. From rem-conf-request@es.net Wed Feb 24 14:02:35 1993 Date: Wed, 24 Feb 93 16:33:13 -0500 From: "Gerard V. Talatinian" Original-Received: by NeXT.Mailer (1.87.1) Pp-Warning: Illegal Received field on preceding line Original-Received: by NeXT Mailer (1.87.1) Pp-Warning: Illegal Received field on preceding line To: rem-conf@es.net Subject: Running vat under SunOS Release 4.1.3? Status: RO Content-Length: 735 X-Lines: 16 I just upgraded a SPARCstation 2 to SunOS Release 4.1.3 (from 4.1.2) and I am unable to get vat to work with the new audio driver. I remember a discussion a while back on this mailing list about a solution to this problem. Could someone email me the information needed to get vat to work with SunOS 4.1.3. Thanks, -Gerard. ****************************************************************** * Gerard Talatinian | * * Network Systems | gtalatin@ucs.indiana.edu * * University Computing Services | FAX: (812) 855-8299 * * Indiana University | Voice: (812) 855-0962 * ****************************************************************** From rem-conf-request@es.net Thu Feb 25 15:01:49 1993 Date: Thu, 25 Feb 93 14:50:04 -0800 From: arc@sgi.com (Andrew Cherenson) To: Joe Ragland Subject: Re: Huh? Cc: rem-conf@es.net Status: RO Content-Length: 872 X-Lines: 41 Joe Ragland writes: >Clinton/Gore @ SGI = 192.48.168.1 > >whois 192.48.168 >Centre National Universitaire Sud de Calcul (NET-CNUSC-DEMO) > 950 rue de St-Priest > B.P. 7229 > F-34184 Montpellier CEDEX 4 > France > > Netname: CNUSC-DEMO > Netnumber: 192.48.168.0 > > Coordinator: > Batllo, Marc (MB247) batllo@FRMOP11.BITNET > +33 67 14 14 14 > > Record last updated on 27-Jan-93. > >Hmmm... Must be Mountain View, France? :-) I called the NIC: the CNUSC net should have been 193.48.168.0. Ooops. Whois: NETBLK-SGI4 Silicon Graphics, Inc. (NETBLK-SGI4) 2011 North Shoreline Road Mountain View, CA 94039-7311 Netname: SGI4 Netblock: 192.48.154.0 - 192.48.209.0 Coordinator: Schryver, Vernon (VS13) vjs@rhyolite.com (303) 786-8846 Record last updated on 06-Jun-91. From rem-conf-request@es.net Fri Feb 26 14:12:58 1993 From: Donald I Hunter Date: Fri, 26 Feb 93 15:06:26 GMT To: rem-conf@es.net Subject: Van Jacobson Status: RO Content-Length: 1057 X-Lines: 26 I've been trying to mail Van Jacobson for a couple of weeks now. He seems to be unreachable at van@ee.lbl.gov, for me at least. This is a last resort. Sorry to everyone else for having to receive this. Van, I'm having a bit of trouble using vat. Once it starts, it runs fine, but it takes about 5 minutes to actually start up. ps lists it as stopped for most of that time too. I was wondering if you would be able to shed any light on this problem ? Also, several vats manage to share the audio device. Is this just using the audioctl device to request the audio device, or is it a more complicated mechanism? At the moment, I'm guessing that it is, but thought you might be able to clarify this point. I am writing a program which will use the audio device to make announcements, while vat is running, so I will need to be able to take control of the audio device. Any comments would be appreciated. Donald. -------------------------------------------------------------------- Donald I Hunter donaldh@uk.ac.hw.cs