Computing Sciences at Berkeley Lab Navigation Banner [Load to Use]

Distributed Systems Department
Collaboration Technologies Group

Information about the Multi-Session Bridge

PURPOSE

The multi-session bridge was developed by Gary Roediger at Fermi Lab for using in bridging multicast and unicast participants in a videoconference. We have primarily used it to either bridge over a broken segment of the MBone or to provide a reasonable level of privacy in a videoconference that cannot be scoped via ttl or administrative domain. The paper describing the Multi-Session Bridge can be found at msbChep97paper.html. Gary has also recently created an updated manual for the MSB.

OBTAINING THE SOFTWARE

The software required to run the multi-session bridge can be obtained from Fermi Lab at the HEP web server. Also please send Gary Roediger e-mail if you are going to use the MSB so he can keep track of usage.

LAUNCHING THE MSB

WARNING: A NEW RELEASE OF THE MSB IS NOW AVAILABLE AND SOME OR ALL OF THE INSTRUCTIONS ON THIS PAGE MAY BE OUT OF DATE! PLEASE REFER TO THE MSB SYSTEM GUIDE FOR UP-TO-DATE INFORMATION. THE INSTRUCTIONS BELOW ARE FOR VERSION 2.0.6 OF THE MSB.

In order to run the multi-session bridge you need two components. You need the msb and the vtc. The msb is the bridge server and the vtc is the client. Before running the msb you will want to create a configuration file. The configuration file contains a description of each of the videoconferences you would like bridged, what media will be used in the videoconference, which sites will connect via unicast, and which multicast addresses are in use. A sample configuration file is

meeting name=inter-lbl user_default_password=lbl
        vat 1 meeting=inter-lbl ip=224.2.209.21 port=16738 ttl=15
        vat 2 meeting=inter-lbl ip=wash1.dc.lbl.gov
        vat 3 meeting=inter-lbl ip=taz.lbl.gov
        vat 4 meeting=inter-lbl ip=tweety.lbl.gov
 
        bridge inter-lbl 1 to 2 3 4
        bridge inter-lbl 2 to 1 3 4
        bridge inter-lbl 3 to 1 2 4
        bridge inter-lbl 4 to 1 2 3
 
        vic 10 meeting=inter-lbl ip=224.2.209.21 port=16734 ttl=15
        vic 20 meeting=inter-lbl ip=wash1.dc.lbl.gov 
        vic 30 meeting=inter-lbl ip=taz.lbl.gov 
        vic 40 meeting=inter-lbl ip=tweety.lbl.gov 
 
        bridge inter-lbl 10 to 20 30 40
        bridge inter-lbl 20 to 10 30 40
        bridge inter-lbl 30 to 10 20 40
        bridge inter-lbl 40 to 10 20 30

In this configuration, the meeting name is inter-lbl and the password needed to join the meeting is lbl. The meeting uses both vic and vat and includes a ttl=15 multicast and three unicast sites. The three sites connecting in via unicast are wash1.dc.lbl.gov, taz.lbl.gov, and tweety.lbl.gov. The bridge statements indicate that full duplex connectivity should be provided between the sites. If the above configuration is stored in the file msb.config then to run the command to run the msb is 'msb msb.config'. The msb expects to be able to get input from standin and to print to standout so do not background the msb. To avoid unnecessary traffic, just running the msb is not enough to cause the bridge to start forwarding traffic.

The msb will not start listening to traffic from a source or forwarding it to a destination until it has heard from a client running vtc at that destination. This includes the multicast addresses. To start vtc listening to the multicast address you must run vtc on at least one client that is not listed on the unicast list. Once you have told the bridge that a multicast participant has connected in then the multicast will always be forwarded from then on regardless of whether the participant that connected to the bridge as a multicast participant continues to run vtc.

When you run vtc, the arguments are the meeting name, machine running the msb, password (the meeting and password were specified in the bridge configuration file and must match). If the meeting name and password match one in the msb configuration file then it first looks for whether the machine running vtc is listed as a unicast participant. If the site is listed as a unicast participant then the appropriate videoconferencing tools are launched with a unicast connection back to the msb. If the machine running vtc is not found in the unicast list then it is assumed to be a multicast participant and the appropriate videoconferencing tools are launched in multicast mode if a multicast address has been specified. If no multicast address has been specified then an error is returned to the vtc.

Versions 2.07 and up of the bridge will allow you to specify that a multicast should always be forwarded by adding the keyword persistent to the configuration file line that specifies the multicast. This can also be used to force forwarding to a unicast machine that can't run vtc.

If you want a machine to be able to connect in with a choice of several options in terms of how it connects in, you can do this by putting a different password on the conferencing lines and then only the line that corresponds to the correct password will be matched. As an example if I had the following three lines in the config file
vic 10 meeting=bee ip=224.2.201.71 port=49992 ttl=127 password=all
vic 11 meeting=bee ip=224.2.239.10 port=50806 ttl=15 password=local
vic 20 meeting=be ip=inch.lbl.gov password=uni
Then a user on inch.lbl.gov could run vtc and specify the password uni and a unicast connection to the bridge would be established. If instead the user had specified local as the password then a ttl=15 multicast session would have been joined. Otherwise if the user specified all it would activate a ttl=127 multicast.

DYNAMIC CONFIGURATION OF THE MSB

The multi-session bridge is designed to dynamic allow modification of the meetings that it is bridging. These modifications are completed through the use of command line arguments to the msb. There are several commands that the msb will respond to. I will try to list the most useful ones here and their syntax. Also, any line that could appear in the msb configuration file could also be typed in as a command line.

First let me give you some vocabulary to make this a little easier to understand. A meeting is a particular videoconference session. A conference is a particular videoconferencing tool on a praticular address (unicast or mutlicast). Each conference is given a id # to identify it and this id is used in bridging statements to bridge it to other conferences.

MSB COMMANDS

quit - causes a clean quit of the multi-session bridge
list all - the msb will list out its current meetings
list msb - the msb will print out a list of the peer bridges
list meet(ing)= - list all only the information about the particular meeting.
delete_meet(ing) - delete the whole meetings name and name2. An arbitrary number of meetings can be specified.
delete_conf(erence) - delete the particular conferences from the meeting. An arbitrary number of conferences can be specified.
delete_bridge - delete the bridge statement associated with the particular id #.
file - read in the commands from the file specified.

PEER MSBs

If you want to run multiple msbs and have them peer to service the same meeting. In the meeting description you also want to use the keyword peer= [machine1], [machine2]. When the msb is run on these machines the master bridge (with the meeting configuration) will attempt to contact them each ~10 seconds to tell them about the meeting. The slave msbs can be running their own configuration files defining them as master for other meetings. If you are only configuring a single meeting the slave bridges can be run without configuration files.

If you are getting udp port conflict errors reported then you need to add the command 'msb_udp_port xxxx' where xxxx is a base port number like 6000. This line should be added near the top of the configuration file.

WARNINGS

delete meeting commands do not work correctly when you have multiple bridges in a meeting.

Be very careful with multiple peered bridges and multicast. If you specify a multicast to be persistent then all the peer bridges will forward the multicast. ALL LINES OF THE CONFIG FILE GET SHARED WITH ALL PEERS leaving room for stupid things to happen in terms of user connections.

Introduction to the MBone Page

Please also visit the

Lawrence Berkeley National Laboratory Home Page.

Distributed Systems Department Home Page.

Distributed Collaboratoratories Home Page.

This document was last updated on July 31, 2001, and is located at http://www-itg.lbl.gov/OldMisc/mbone/msb.README.html.

To report Web page problems, e-mail webmaster-george@george.lbl.gov.

Support Credits identify the funding sources and the organizational context of the work described in this document.

Privacy and site security notice to Users .

Deb Agarwal (DAAgarwal@lbl.gov) is responsible for this WWW document.