Most readers of this book probably already know that numerous vendors offer high-bandwidth, near-broadcast quality, schedule-invasive teleconferencing that requires specially equipped conference rooms, video and audio technicians who ride shotgun during the conference, a separate dedicated network between all teleconference sites, and a convenient place to pour all the excess cash in your budget.
What you may not know is that if you're willing to suffer the slings and arrows of outrageous fortune on the bleeding edge of the Internet, you can engage in teleconferencing over your existing Internet infrastructure with moderately little investment in time and equipment.
Not everything used for teleconferencing can talk to everything else. The tools and the dynamics of a "typical" Internet teleconference can vary not only from site to site, but from conference to conference as people switch software depending on what the people on the other end are using.
A typical Internet teleconference can be between two or more people using a freely available package called CU-SeeMe. CU-SeeMe provides audio/video teleconferencing on a Mac and video-only teleconferencing on a PC. In the example shown in Figure 19.1, the participants are conferencing over their desktop computers at frame rates that vary between .5 and 15 frames per second (depending on the available bandwidth).
FIGURE 19.1. Internet teleconferencing can be a highly valuable tool in bringing together diverse locations. This keepsolid session lets anyone on the Internet with keepsolid software participate.
Look at the Participants window menu (shown in Figure 19.2) to see the chosen session nicknames of the video participants and several "lurkers" as well (these folks may be people without the ability to send video, who have chosen not to actively participate in the conference, or who have been blocked from participating because the conference is using a private conference ID number).
FIGURE 19.2. Ubiquitous teleconferencing is another reason to become a mouse potato. Freely available software like keepsolid permits teleconferencing on-the-fly.
Each of the active participants can send audio to the group; alternatively, he or she can click the microphone symbol at the bottom of another participant's video window to speak privately with that individual.
What's important about the conference is that it takes place over the same Internet infrastructure that the participants' e-mail, file server, Usenet news, WWW, and other traffic also occupies. This is both good and bad.
The benefit of teleconferencing on the same Internet you use for everything else is that you no longer need an entirely separate network and set of conference rooms to do teleconferencing. In addition, the number of people you can reach just exploded. Now, virtually anyone with 56 Kilobits (Kb) or better bandwidth access to the Internet can engage in teleconferencing by adding some freely available software and minimal hardware to their Macintosh, PC, UNIX, or VMS workstation.
The down side is that because your teleconference shares the same bandwidth as your other applications, it can also negatively impact the performance of those applications, slowing down the workplace for the benefit of a teleconference that may or may not be as important as the other traffic it displaces.
Internet-based teleconferencing doesn't lend itself well to every teleconferencing application. If, for example, the purpose of a teleconference is to review video of industrial time/motion studies, critically analyze sports performance at normal speed playback, or play a string quartet with each player in a different location, you are far better off looking at one of the proprietary solutions, at least for the time being.
If, however, you want to have off-the-cuff conferences with numerous associates who may be anywhere from a couple hundred feet to several thousand miles apart and do so with little or no advance setup, without leaving the desk in your office or home, the present state of technology in Internet teleconferencing holds promise.
What kind of performance can you realistically expect? The technology discussed in this chapter can usually be relied on to deliver 10 to 15 frames per second of video on the same LAN, 5 to 15 frames per second between different LANs at the same site, and 0 to 15 frames per second of video between any two arbitrary Internet sites with no intervening circuits of less than 56 Kilobit bandwidth. Your mileage, of course, will vary depending on numerous factors. These factors include things such as how many other applications are relying on your network and the demands those applications make on the available bandwidth. More subtle issues also come into play, such as how often the scene changes in any given video window. (This is important because the video applications discussed here use something called velocity compression, which gives priority to updating fast-changing parts of a scene before updating more static portions. Because of this, you may see a partial image for a minute or so when you bring up a new video conferencing window.)
Audio performance is the other factor that depends greatly on immediate bandwidth availability. The dynamics of human communication are such that most teleconferences (those between people who can both see and hear) communicate more information through audio than through video. If the video portion of the connection begins to drop frames, the result is usually just annoying. If audio drops off, it often means more than just the loss of a few seconds of audio: you often lose additional time asking for something to be repeated and repeating it. Many types of conferences, however, don't lend themselves well to interjections from the audience; the bit of audio information that dropped out may just be lost; the listener has to imagine what may have been said, with the result that he or she understands that much less of the subject material.
Other teleconferencing components (such as slides) are almost equally well suited to spotty communications and good, wide-bandwidth networks. These kinds of elements take longer to communicate and the user can request retransmission within the application without impacting the people involved. Displays of slides or scheduling information don't have the real-time demands of audio and video and therefore can be considered to have comparatively negligible impact on network resources.
Once you start Internet teleconferencing, you should be aware of some signs that indicate you could be better off using another type of teleconferencing until Internet tools are available that do what you need or until the present tools improve to do what you want. Such signs include the security demands of the teleconference, the reliability of product support, and a requirement for consistent, broadcast-quality teleconferencing.
Two audio clients described here, Visual Audio Tool and Network Voice Terminal, each offer DES encryption to provide greater security and privacy for conferencing. Other types of Internet teleconferencing clients, such as video and whiteboard applications, don't offer encryption. This means that although most of the information in a teleconference can be concealed from all but the most skilled intruders, the video, whiteboard, and other data streams are not encrypted, leaving potentially vital portions of your conference open to the public. (Because the conference is transmitted over numerous local and wide area networks, any curious people can watch the packets race by on their local Ethernet and snoop on your conference without your knowledge.) Doing so is beyond the expertise of the vast majority of Internet users, but then again, the vast majority of Internet users aren't predisposed to intentionally violate other people's security.
Frequently, the "you get what you pay for" principle of economics fosters a belief that software acquired from the Internet is necessarily bug ridden and functionally unsupported. An unfortunate fact is that many commercial and academic sites don't embrace Internet teleconferencing because they mistrust anything that doesn't cost an arm and a leg. This, no doubt, stems from a desire for ultimate accountability—to have someone take responsibility for the failure of a product. Experience indicates that paying more for support doesn't necessarily result in a better product. No computing product, be it software or hardware, is used in an environment in which all equipment and software come from a single vendor. Finding such genetically pure computing environments is about as likely as finding an entirely American-made automobile.
In real-word, composite environments, vendors have traditionally dismissed errant product behavior as caused by some other vendor's product. Clearly, a commercial commitment to support doesn't always mean that the vendor will even acknowledge the problem. The argument in favor of using only commercially supported packages can degrade to this: even if actual support is unavailable, identifying a specific vendor with a given system results in a target for litigation. Management by lawsuit, however, isn't management at all but the failure thereof.
Using applications developed and informally supported through the Internet doesn't necessarily mean that the support is substandard or below the level available through commercial channels. The most substantial difference between informal Internet-based support and commercial support is that the burden for evaluating the reliability of multiple, often contradictory, sources of support rests with you, the customer. Unlike bandwidth and restrictive legislation, ego is never in short supply on the Internet. The more obscure your problem or request, the more likely you are to get detailed descriptions of what you need to do or where you need to go. Relying on the Internet for support of major resources, therefore, is less of a journey to the Oracle and more of a trial by jury. The a posteriori nature of Net-based support means that if you are doing anything non-unique, chances are that many people on the Net have already worked out a way to do it. It may even be valid to argue that the Internet can better support some applications because it is more of a melting pot than any single vendor's support facility; such an environment yields more valuable experience than a vendor-pure lab.
NOTE A priori can be found at http://www.nr.no/ordbok/engelsk?a+priori; a posteriori can be found at http://www.nr.no/ordbok/engelsk?a+posteriori.
The Holy Grail of teleconferencing is so-called broadcast-quality video with video frame rates of at least 24 frames per second and audio sampling on par with compact discs. Developing standards such as H.261 coding hold great promise for high-quality teleconferencing, but the current state of Internet teleconferencing is a level of magnitude less than the glitchless broadcast-quality product available with commercial products. Without a doubt, many applications require that level of quality—even at the cost of a parallel network to carry it and a parallel staff to run and maintain it. Even in such situations, it may be possible to reserve the "fine china" of a dedicated teleconferencing infrastructure for occasions that require it and to use the "paper plate" applications from the Internet when the type of conferencing needed doesn't justify the economics of the larger system.
If none of the issues just discussed have torpedoed your enthusiasm for Internet-based teleconferencing, let's move on to some even grayer issues such as bandwidth use, interoperability, and site security.
The best and worst thing about Internet teleconferencing is that is uses the same network you use for everything else—from frivolous perusals of packetized flights of fancy to the most mission-critical NFS mounts, Netware file services, and SQL databases. Some LAN and WAN protocols offer traffic prioritization, but not all hardware supports it, nor do most networks use such protocols. The bursty nature of teleconferencing can drag the available bandwidth of your network down and can cause noticeable or significant decreases in the availability of services from other relatively high-bandwidth applications like file servers, X Window, large-scale network management, and so forth.
These are not insurmountable problems. Some applications can assist your efforts to make the teleconferencing as nonintrusive to the other tasks on your network as possible. The INRIA Video-Conferencing System (described in "The Applications," later in this chapter) can automatically control the bandwidth it uses by monitoring feedback information it receives over the network. Most broadcast applications can be adjusted to have an upper threshold for transmission bandwidth. The CU-SeeMe reflector that enables many-to-many communication with the CU-SeeMe software for microcomputers can place a hard limit on the bandwidth any particular client can use, disconnecting them for a preset amount of time if that limit is exceeded.
In addition to the available technical constraints, social constraints are also a good idea. A little peer pressure applied at appropriate points can go a long way toward taming the human and software bandwidth hogs. After a little initial testing, you should be able to determine whether your network can bear the load of one or two teleconferences, each with three of four video participants and three or four "lurkers" (non-transmitting participants who just watch and listen). Before long, you should have a feel for whether you can be indiscriminate about when you teleconference or whether you should wait for periods of nonpeak usage.
No new application is born into a vacuum, and teleconferencing is no exception. You may already have existing teleconferencing, telemetry, or other remote-sensing systems that must tie into your teleconferencing system. Niche requirements can make demands on your teleconferencing system that off-the-Net software cannot address.
The level of security required for the information transmitted in a teleconference can easily rule out the feasibility of Internet teleconferencing. A more subtle issue is the degree to which your internal network must be opened to teleconference with external sites. Most security firewall arrangements, whether protocol or host based, can accommodate teleconferencing without sacrificing anything but bandwidth, privacy of teleconference content and methods, and the minimal information about your network architecture that can be gleaned from teleconference traffic.
These are some of the larger issues you should think about as you consider making the move to Internet-based teleconferencing. Certainly, teleconferencing is so useful—and just plain fun—that it's probably a one-way street. Any organization introduced to Internet teleconferencing is no more likely to go back to not using it than they are to stop using the World Wide Web once they start that.
MBone: A Multimedia Backbone for the Internet
The Internet has a few different teleconferencing infrastructures, each with a limited amount of interoperability. One, CU-SeeMe, is a development project funded by the National Science Foundation and has taken the approach of loading all the functionality into a single piece of software. The other, the Internet Multicast Backbone, or MBone, carries its multimedia conferences to and from a wide variety of software. Although the software for both these networks can facilitate conferences between just two people without any kind of special network accommodations, the following discussion covers the wider possibilities of many-to-many conferencing.
The summer of 1968 may have been the summer of love, but 1988 was the summer of the MBone, and there was a "whole lotta hackin' goin' on." During that summer, the first Internet multicast took place, appropriately enough, between two of the original four ARPAnet sites: Bolt, Beranek, and Newman (BBN) and Stanford University (both of which have been important contributors to the Internet since 1969—before it was called the Internet).
The MBone (see Figure 19.3) relies on a type of networking called IP multicasting. Multicasting is a kind of middle ground between unicasts (in which one computer communicates with one other computer) and broadcasts (in which one computer talks to all the computers on a particular network). When one computer multicasts, it sends information to a group of computers, not all of which may be on the same network.
FIGURE 19.3. A monument to creativity and ingenuity, the MBone is one of the most successful experiments undertaken on the global Internet.
Since the early conferences in the late 1980s, the MBone has grown steadily; by the end of 1994, it included over 1,200 individual networks. The content of the MBone has grown from simple documentation of the Internet Engineering Task Force meetings to a variety of programming from underwater research to speeches at the National Press Club.
Following are brief summaries of several applications that run on the MBone. All these applications run on UNIX (or something similar, depending on your talent at porting source code). With the exception of Shared Mosaic, each of these applications can be found through URL http://www.eit.com/techinfo/mbone/mc-soft.html. Shared Mosaic can be found through URL http://www.eit.com/software/mosaic/sh-mosaic.html.
Lawrence Berkeley Lab's Visual Audio Tool (VAT) (shown in Figure 19.4) is the software used for most audio conferencing on the Internet. VAT's features include automatic input and output gain control, a conference/lecture mode toggle, and a VU meter and volume slider for both input and output. The user interface is also modifiable using the popular Tool Control Language.
FIGURE 19.4. LBL's Visual Audio Tool.
VAT can encode and decode in a variety of audio formats with a range of bandwidth requirements from 9 Kbps to 78 Kbps. At press time, work was being done on a 4,800 bps format; a 2,400 bps format was being considered. VAT can also serve as a mixer to adapt bandwidth and mix numerous audio streams into a single stream, or as a converter from one audio format into another.
VAT can send and receive DES-encrypted audio streams. Because most teleconferences over the Internet don't yet have the frame rate to make lip-reading practical, encrypted audio serves to conceal a great deal of the information conveyed in any given conference.
Network Voice Terminal (NeVoT) is an audio client from Henning Schulzrinne of GMD Fokus in Berlin (see Figure 19.5). Like VAT, NeVoT includes an interface controlled by the increasingly popular Tool Control Language, the ability to operate in either gateway or client mode, the ability to run several conferences at once, and the ability to use DES-based voice encryption. Unlike VAT, NeVoT can run in either mono or stereo mode.
FIGURE 19.5. The Network Voice Terminal MBone audio client.
NetVideo, also referred to as nv, is the most widely-used MBone video client. As seen in Figure 19.6, NetVideo permits transmitting stations to control the bandwidth they use. Given appropriate hardware, NetVideo also permits the user to switch between sending black-and-white or color images. NetVideo can encode video in numerous formats, including Cornell University's CU-SeeMe (refer to "Teleconferencing on a Beer Budget: CU-SeeMe and Maven," later in this chapter).
Figure 19.6. Netvideo can transmit video from a video camera, but it can also use an X Window as a display source (such as the rebroadcast FrameMaker window shown here).
In addition to conventional NTSC or PAL video input, NetVideo has also incorporated a number of "grabbers" that grab video from workstation displays and feed the contents or partial contents of a display window into a conference video stream. Different display types use different grabbers. Some displays show stills of the grabbed area; others show the grabbed area dynamically in real time.
INRIA Video-Conferencing System (IVS) is a one-stop shopping application for audio/video teleconferencing. The software in the IVS system, IVS (see Figure 19.7), ivs_replay, ivs_playback, and ivsd combine to give the user a single application cluster that receives and sends both audio and video in numerous encoding formats. The combination also records and replays previously recorded conferences and can notify you when another IVS user wants to conference with you.
FIGURE 19.7. The INRIA Video- Conferencing System has the useful feature of being able to "page" people to engage them in a teleconference.
VIC, the Internet video conferencing tool in the Lawrence Berkeley Laboratory Network Research Group suite of multimedia teleconferencing tools (see Figure 19.8), was still in beta test at press time, but was nonetheless available to the general Net public. VIC's strong points include voice-activated video switching and the ability to use H.261 video encoding.
FIGURE 19.8. The flexible VIC is Lawrence Berkeley Lab's contribution to the video part of Internet teleconferenceing.
The Shared Whiteboard Tool (wb) is LBL's version of a combination whiteboard and slide projector. Participants can import plain text or PostScript source files; they can also use built-in drawing tools to enhance or create new images on the multipage whiteboard display (see Figure 19.9).
FIGURE 19.9. This electronic whiteboard lets numerous users around the world display pages of text and graphics and mark them up simultaneously.
The IMage Multicaster (IMM) client pictured in Figure 19.10 is an MBone client designed for low-bandwidth background downloads of images such as satellite imagery and art gallery images. An advantage of using IMM over other applications to download a series of files is that through the use of IP multicasting, IMM can download the same files to all the participants in a given session simultaneously, making corrections for individual errors afterward when necessary.
FIGURE 19.10. IMM has a creative answer to the load problem of many people downloading the same graphics from the same place.
Enterprise Integration Technologies' Shared Mosaic is an extension of NCSA's Mosaic for X. Any two normal IP unicast machines can use Shared Mosaic to cooperatively browse the Web in a one-to-one conference. Any reasonable number of workstations equipped to handle IP multicasting can cooperatively browse the Web as well. The synchronization model is described as "loosely controlled"—a nice way of saying it's a free-for-all. Anyone can control the browsing.
Once you have all these nifty MBone clients (or as many as you could fit on your available storage), you're ready to teleconference. Calling someone on the phone to tell them you want to teleconference seems a bit out of the spirit of things. If you're not running IVS and IVSD, how are you supposed to go about coordinating things?
The most popular way of coordinating conferences is with a session directory, or SD (see Figure 19.11). SD is a kind of automated television schedule. Persons who want to advertise a conference can set it up in SD, plug in whatever parameters they need, specify whether they're doing video, audio, and/or whiteboard, give the time, date, description, and a few other things, and their entry shows up in a list of upcoming and current conference events in the application's main window. All anyone has to do at that point is double-click the listing to start up all the required clients with the appropriate parameters to participate in the conference. Not surprisingly, the particular clients used for different types of sessions (video, audio, and so on) are controlled by a TCL script.
FIGURE 19.11. A kind of television schedule for the MBone, Session Directory lets you schedule and advertise your own conferences as well as launch you into others' conferences.
If Session Directory is a kind of television guide, the Multimedia Conference Control (MMCC) program delivers video on demand. Users of MMCC (shown in Figure 19.12) can page one or more other users of MMCC and engage them in a teleconference. With MMCC, you don't have to schedule a meeting ahead of time and you can restrict your guest list to a subset of folks running MMCC.
FIGURE 19.12. Naturally, all teleconferences aren't for public consumption. The MultiMedia Conference Control program helps coordinate and initiate multiparty Internet teleconferences.
The MultiMedia Phone Service, MMPhone (shown in Figure 19.13), is specifically designed for unicast (one-to-one) teleconferencing. Users indicate the parameters of their conference on a World Wide Web form that they submit; their correspondent receives a MIME-format mail message with all the necessary information to begin the session.
FIGURE 19.13. The MultiMedia Phone Service uses existing Web tools to coordinate one-to-one teleconferencing. Fill out the form; your local software runs automatically and an e-mail invitation goes out to the other party.
The checklist for being on the MBone includes an IP route to an MBone provider that can route IP multicast packets to you over your existing 56 Kb or better Internet connection, and presumes routers that can do IP multicasting or a UNIX machine running mrouted, the IP multicast router daemon.
It is necessary to acquire an MBone "feed" and UNIX machines acting as multicast routers (also called mrouters) because IP multicasting is not a feature built into all, or even a majority, of Internet Protocol routers today. Because the call for this feature has thus far outstripped the ability of the industry to meet demand, the freely available mrouted software is used on UNIX machines to "tunnel" IP multicast traffic inside conventionally routed IP traffic to build a network within a network: the MBone.
The industry is beginning to recognize the value of this technology; some UNIX-style operating systems such as SGI Irix 5.x, DEC OSF 2.x, BSDI, NetBSD, FreeBSD, and Sun Solaris 2.x, now have the ability to do IP multicasting without third-party patches to the kernel of the operating system. For those systems that require patches to be full players on the MBone, the patches, along with the mrouted software can be acquired through URL http://www.eit.com/techinfo/mbone/mc-soft.html for the client software.
Some microcomputer-based software with a limited amount of interoperability can interact with the MBone. The following discussions are limited to software that has at least a limited amount of interoperability with the MBone. Although other software (such as Internet VoiceChat) shows a great deal of promise, discussion of software that doesn't interoperate with the MBone is beyond the scope of this chapter because it doesn't contribute to the availability of a single teleconferencing infrastructure.
Cornell University's CU-SeeMe (see Figure 19.14), developed at the Cornell Information Technology organization (CIT), is a teleconferencing application that comes in two flavors: a Mac-based client and a PC-based client. At press time, the Macintosh client supports audio, video, and a "talk" interface in which participants can type to each other; the PC client was video-only, but an audio version was in alpha-testing. At press time, both versions only supported black-and-white video.
FIGURE 19.14. Now every office can have a window with a view—here, CU-SeeMe tunes in to the NASA Select network while there's a mission.
Like its MBone cousins described earlier in this chapter, CU-SeeMe can be used with no additional software for point-to-point, one-on-one teleconferencing—just like an ordinary telephone call. The addition of UNIX-based "reflector" software, however, permits a CU-SeeMe client to send its video (and audio and talk, if from a Mac) transmission to the reflector machine, to which any number of additional CU-SeeMe clients can attach and participate or simply lurk.
CU-SeeMe has become the Model-T of Internet-based teleconferencing. It's the first teleconferencing application that doesn't require a comparatively high-end workstation or operating system but has captured the enthusiasm of a global audience. A recent indicator that CU-SeeMe had gained acceptance into hitherto unpenetrated markets was the CU-SeeMe-based pay-per-view broadcast of the Houston livestock show and rodeo. Whether it's a live broadcast from a Space Shuttle mission or a view of someone's empty office in Norway, CU-SeeMe is quickly becoming the most ubiquitous teleconferencing application on the Net.
Maven, named after a Yiddish word for knowledgeable person, is an audio conferencing application for Macintoshes. Maven can use four encoding formats: u-law, which is a good lowest common denominator when interacting with other teleconferencing applications; Intel DVI, which is used by VAT; Linear, which is the native Mac audio format; and u-mod, which uses comparatively little bandwidth at the expense of some audio quality.
Maven (shown in Figure 19.15) requires no reflector to work, although the CU-SeeMe reflector has made accommodations for Maven/VAT audio format (refer to "Tab A and Slot B," later in this chapter).
FIGURE 19.15. Maven is the audio software used in the Mac version of CU-See Me. Here, a Maven user talks to two VAT users, neither of whom can hear each other, but both of whom can hear the Maven user (who can hear them all).
Once you start Maven, you can add participants one at a time; such participants can be copies of VAT or the CU-SeeMe reflector or other Mavens running on the Net. Participants can be removed from your list only if they shut down—there's no facility short of quitting Maven for removing participants from a conference yourself.
Many folks are using Maven without realizing it. The code for Maven was included in the Mac CU-SeeMe for the sound functionality (which makes it a little easier to understand why the Mac CU-SeeMe client is the only one so far that has been in general release with audio support).
Setting up an MBone site is considerably more labor and time intensive than bringing yourself up with CU-SeeMe. Both MBone and CU-SeeMe require an IP route between each of the participants and either the mrouter or the CU-SeeMe reflector for many-to-many communications. The requirements in addition to the IP level are, in both cases, narrow enough to afford what would be adequate firewall reliability in most circumstances. Both MBone and CU-SeeMe software can be used for point-to-point communications.
One difference between CU-SeeMe and IP multicast clients is that you can be up and running on CU-SeeMe inside of five minutes by downloading a list of public or semi-public reflectors and the appropriate client for your machine and then running it. As long as you have a working WinSock or Mac TCP installation (whichever is appropriate), no installation is necessary for CU-SeeMe besides putting the software where you want it. Configuration is possible with both clients, but not required. With a stripped-down Mac, you can be watching and listening to conferences all over the world as soon as you bring up the software. The Cornell University reflector is usually a good place to find a conference that includes people from all over the country or the world.
If you have a Mac AV, you can plug in your mike and a camcorder and be a full player right now. If you have a nonAV Mac, you can use a digitizer board or a Connectix Quick-Cam (a serial-attached camera, digitizer, and microphone that costs around $100).
Although going from zero to CU-SeeMe can take about 5 minutes, bringing up each MBone client takes a bit longer, depending on how you go about it. Many FTP sites have precompiled binaries for the most common machines and operating systems. If you decide to use a precompiled binary, at least for initial evaluation, each installation of an IP multicast client should take about 5 to 10 minutes to complete. If, however, you prefer to start with source code and compile your clients to optimize them for your individual system, allow at least a half hour to an hour to take each client from download to startup.
Once you have your clients set up and have tested them against public CU-SeeMe reflectors or with point-to-point conferencing, what's next? If you decide to go for many-to-many conferencing using your own infrastructure, you must bring up a CU-SeeMe reflector or an IP multicast backbone. The former can be done in about 10 to 15 minutes (including the time it takes to read the documentation). The latter route involves several strategic decisions with regard to who you want to get your IP multicast feed from, where you want to run your mrouted daemons, which organizational subnets can handle the load of teleconferencing, and most important of all, what you're going to do to maintain this beast and ensure that present and future employees know how to make appropriate use of it.
Without common standards to link these teleconferencing tools, all you would have is a virtual tower of Babel. The key pieces in interoperability between microcomputer-based teleconferencing and IP multicasting are NetVideo, the CU-SeeMe reflector, and VAT. Naturally, any audio clients that use Intel DVI encoding can serve the same role as VAT in this equation; any video clients that use CU-SeeMe encoding (currently, only NetVideo fits this bill) can serve the same role as NetVideo.
To understand how things work together, it's necessary to understand the reason for the fundamental difference between the MBone and the CU-SeeMe architectures. Typically, clients that participate in the MBone are capable of IP multicasting (meaning that they can share the burden of distributing their traffic to an arbitrary group of computers that may or may not be on the same local area network). Typical clients that participate in CU-SeeMe (PCs and Macintoshes) cannot support IP multicasting. This means that their audio and video transmissions must go to an intermediary piece—a reflector—to be made available to other CU-SeeMe clients. Those other CU-SeeMe clients, however, are equally unable to support IP multicasting, so they must connect to the reflector to participate in a conference.
A notable side effect of this is that although both CU-SeeMe and MBone-based conferences can have numerous video and audio streams in a single conference, CU-SeeMe is currently limited to participating in only one conference at a time. A workstation on the MBone, however, can participate in as many conferences as practical hardware limits permit.
Getting on board with Internet teleconferencing is not unlike being one of the Mercury seven. As you learn about the MBone and CU-SeeMe, a lot of your satisfaction will come from seeing it get off the ground. The quality and strength of the tools involved is increasing just fast enough to keep you from resting on your laurels for any comfortable period of time.
It's impossible to guarantee that things will work well all the time, that you will always have at least 10 (or even 5) frames a second of video, or even that every teleconference will be worth the effort it takes to set up. What is likely, however, is that, as with any new communications medium, you will begin to use Internet teleconferencing to replace some of the media you already use (such as the telephone and e-mail). You will also find new ways to exploit this technology to do things that were so impractical before that they never occurred to you.
Following are a few URLs that can help you move on in your own research to discover whether Internet-based teleconferencing is for you. It's probable that your first successful teleconference on the Internet will inspire the same enthusiasm and amazement as your first time at bat with NCSA Mosaic. One thing is certain: Internet teleconferencing will have no less of an impact on the world than Mosaic did on the World Wide Web.
and Maven Starting Points
