Multicast within a single physical network is simple [25]. Problems arise when one wants to use multicast across physical network boundaries. How should a network router decide which packets are to be transported to the outside world, and to what destinations? The Internet Group Management Protocol (IGMP) [42], implemented in the network layer, is used as a solution, aiding hosts and routers in maintaining tables of which hosts belong to which multicast groups. Hosts send IGMP reports when the first process enters a multicast group. Nothing is sent when processes leave a group, but routers send queries periodically, to generate new reports from the hosts.
Hardware routers supporting multicasting are currently not widespread. Instead, software routers, called tunnels, are used, encapsulating multicast packets inside regular IP packets. When enabling exchange of multicast packets between two physical networks, a single host on both networks are typically set up to run mrouted, the multicast routing daemon. It is expected that commercial routers will support multicast in the near future [43], removing the need for software routers.
A set of multicast capable networks, called islands, ``connected'' using tunneling mechanisms, makes up the MBone (the Multicast Backbone), a ``virtual network running on `top' of the Internet'' [44]. The MBone started out as an experiment during the Internet Engineering Task Force (IETF) March-meeting in 1992, located in San Diego. Live audio was sent using multicast transmission to participants at 20 sites on three continents [45]. Over the years, software have evolved enabling other media to be transferred in addition to sound. Today, the MBone is used not only for teleconferencing: In 1993, the Woods Hole Oceanographic Institute used the MBone for transmitting telemetry data from and undersea vessel. Satellite weather photos are transferred as still images, and live activities from space shuttle missions are transferred from NASA's cable TV channel ``Select'' [46].
Video conferences, lectures, and other transmissions of video and sound on the MBone, are often announced to draw attention from the people interested in participating. During the lifetime of a video conference, participants may arrive and leave at various times. A need to invite new participants may also be present. If the conference is encrypted, mechanisms must be available for distributing encryption keys among the participants. Tasks like these are handled using session management protocols.
Session management protocols are currently being specified by the Multiparty Multimedia Session Control (mmusic) workgroup of the IETF. Draft documents are available, and programs implementing the current state of some of the standards exist. The draft standards include:
This section shortly describes a few Unix conference utilities often used on the MBone.
sdr, shown in figure 3.5, is a session directory for announcing and scheduling multimedia conferences on the MBone. The program allows users to set up new conferences, or to list and join existing conferences by launching helper applications handling video, sound and shared workspaces. sdr uses the draft standards mentioned in section 3.2.1 to perform it's tasks.
Figure 3.5: sdr main and session
information windows.
The left hand window in figure 3.5 shows the main window of sdr, containing the dynamic listing of currently announced sessions on the MBone. The ``New'' button on the main menu allows the user to announce a new session. When pressing the button, a window (not shown) pops up, asking for information to be broadcasted about the new session.
By clicking on a listed session, the right hand window pops up, giving detailed information on the session in question, including transmission data formats. The window allows users to join the session by launching programs to decode some or all of the transmitted data.
The programs vic and vat, whose main windows are shown in figure 3.6, may be started either by sdr, or as stand-alone programs to handle video and audio conferences respectively.
Figure 3.6: vic (left) and vat main
windows.
The vic window to the left in figure 3.6, shows one sender, with the transmitted frames on the left, and information on the right. One may click on the frame window for an enlarged view. The transmitting participants are shown in the main window, while a list of spectators are available under the ``Menu''-button. By default, vic doesn't send video until told so by enabling ``Transmit'' under the ``Menu''-button. The program supports various video formats, including H.261 and MPEG.
The right hand vat window shows all participants, including those not transmitting. As for vic, transmission is off by default. The one currently talking is highlighted.
Shared workspaces or whiteboards, are tools that may be used along with video and audio for video conferencing or lecturing. Figure 3.7 shows the program wb in action.
Figure 3.7: wb main and whiteboard
windows. (The whiteboard window is slightly shrinked.)
The main window on the left, shows the current participants. The right window is the actual workspace, where users may write text and draw graphics.