Before you can begin using InPerson, you need have your network administrator prepare the network. This chapter provides a checklist for successful setup, and includes step-by-step instructions for the network administrator. This chapter includes:
After you have installed the InPerson software, do the following:
If you will be using an ISDN to place InPerson calls, go to the Appendix, “Using InPerson Across an ISDN Line.”
Determine the type of conferences you will have—point-to-point conferences (between two systems) or multiway conferences (between three or more systems).
Determine where the systems are located—on the same physical network or on different networks.
Contact your network administrator.
Tell your network administrator that you will be using InPerson. InPerson sends audio and video data across the network. Network use may increase as a result.
Verify what kind of network you are using for InPerson—ISDN, T1/E1, LAN, or high speed LAN. Then, make sure that the correct type is checked on your Call Preferences panel. See “Setting the Network Bandwidth for Your Network Type” for step-by-step instructions.
If you want to have multiway conferences between systems that are on different networks, ask the network administrator to configure the network using the instructions in “Preparing Your Network for Multiway Conferences.”
Different network types have different network bandwidth ranges. For example, ISDN is a low-bandwidth network and LAN is a higher-bandwidth network. Use the Call Preferences Panel to tell InPerson what kind of network you are using, so it can set the best bandwidth range and compression schemes for your network type.
To do this:
Place the cursor over the phone and press the right mouse button.
Choose “Call preferences panel...” from the popup menu that appears.
The Call Preferences Panel appears.
Next to the label Network Bandwidth, click on ISDN, T1/E1, LAN (for example, Ethernet), or Hi-Speed LAN (for example, FDDI/CDDI, ATM), depending on the type of network you are using.
A blue triangle indicates your selection.
Note: If you open the Fine Control section of the Call Preferences Panel, then click from one network type to another, you can see that the Bandwidth Limit slider changes to display the appropriate bandwidth ranges for different network types. To save this as the default setting for future calls, click Save, then click the OK button.
 | Tip: After this range is set, you can still alter the target bandwidth limit and compression schemes within that range. Do this by moving the Bandwidth Limit slider on the Call Preferences Panel or Call Control Panel. Whenever you increase the bandwidth, keep an eye on the CPU Usage and Network Demand graphs so that you are aware of how much you are using these resources. Too much CPU usage will slow down the programs currently running on your system; too much network demand will slow communications between all the systems on your network. |
A multiway conference includes three or more systems, some of which may be located on different networks. InPerson transmits information between these networks using multicast packets. As a result, a network administrator needs to configure the network so it can route multicast packets. The rest of this section provides instructions for the network administrator.
| Note: InPerson multiway conferences are not supported over ISDN. |
Analyze the network configuration.
Find out which systems will be using InPerson for multiway conferences.
Determine the location and type of routers in between these systems. If the network is a single subnet and doesn't use any routers, the network is already prepared for multiway conferences. InPerson will work without any changes to the network configuration.
Enable multicast routing by doing one of the following:
If you have Silicon Graphics systems as routers, see “Turning On Multicast Routing” to learn how to turn on multicast routing using mrouted. If you have another type of router that supports multicasting, refer to that vendor's documentation.
The Silicon Graphics token ring network boards do not support multicast routing.
If you have routers that don't support multicasting, see “Setting Up Tunnels to Support Multicast Packets” to learn how to create “tunnels” between the networks. The multicast packets travel from one network to another through these tunnels.
If your site has multiple logical IP networks on the same physical network, you will need to create tunnels. Multicast routing using mrouted isn't supported on these networks.
If your network is running NIS (formerly known as YP), update the /etc/rpc file on the NIS master. See “Update /etc/rpc for NIS Users” for details.
If you're using Silicon Graphics workstations as routers, you can turn on multicast routing by doing the following:
Identify the routers on each network that need to support multicasting. Make sure that the routers you select are running IRIX 4D1-5.3 or later.
If you haven't already done so, install on each router the eoe2.sw.ipgate subsystem from your IRIX 4D1-5.3 distribution source. Run autoconfig(1M) if necessary.
As root, type: chkconfig mrouted on
Restart the system.
Figure 1-1 shows an example network with three routers. Each bubble labeled InPerson represents a person who is using InPerson on a system in the network.
If people on networks A, C, and D are participating in a conference, as shown in the figure, all four networks receive the multicast packets.
If people on networks A and C are participating in a conference, networks A, B, and C receive the multicast packets.
If three or more people on network A are participating in a conference, networks A and B receive the multicast packets. The multicast routing protocol prevents packets from being sent to “leafs” of the network, such as networks C and D; however, it doesn't prevent packets from being sent to interior networks, such as network B.
You can use the program testmcast to see where multicast packets are being sent on your networks. See “Tracking Multicast Packets” for details.
| Note: The time-to-live (TTL) setting specifies the number of routers through which the multicast packets will pass. A system administrator can adjust this setting using the instructions in “Adjusting the Network TTL Setting.” |
If your routers do not support multicast routing, you can support multicast packets by creating “tunnels” between the networks. Any Silicon Graphics workstation running IRIX 4D1-5.3 or later can be configured as the endpoint of a tunnel. With tunneling, the multicast packets are encapsulated inside unicast packets, and then are sent to the other end of the tunnel. They are converted back into multicast packets when they are received.
Figure 1-2 shows an example of a setup with tunnels.
To create the tunnel, you edit the file /etc/mrouted.conf. Step-by-step instructions follow:
Select the systems on each network that you will use for the sending and receiving end of the tunnel.
Choose a system that's running IRIX 4D1-5.3 or later, is fast, and is not used extensively. The audio and video data may be intermittent if the system you select is slow or overloaded.
If you haven't already done so, install the eoe2.sw.ipgate subsystem from your IRIX distribution source.
As root, edit the file /etc/mrouted.conf on the sending and receiving end of the tunnel. Note that these endpoints can be separated by many routers; you can use any machine on the network that is running IRIX 4D1-5.3 or later.
Add the following line for each network to which you want to establish a tunnel.
tunnel <local IP address> <remote IP address>
In the above example, the system on network D would have the following entry:
tunnel 192.26.58.1 192.48.170.2
The system on network A would have the following entry:
tunnel 192.48.170.2 192.26.58.1
You can specify other optional settings for the tunnel. For details, see the mrouted(1M) man page.
Restart the system.
| Note: One copy of the multicast packets is sent for each tunnel entry in mrouted.conf. This results in extra network traffic. For example, suppose you have a workstation with one network interface and you set up tunnels to workstations on three other networks. The packets are replicated three times. |
If users can't hear or see other participants in a conference, use the program /usr/lib/InPerson/testmcast to verify that multicast packets are being forwarded correctly on your networks. testmcast sends a multicast packet every five seconds and prints a note saying it's been received. To use it, you need to set up each participating workstation to send and receive these test packets.
To verify the initial multicast setup of systems you want to communicate with in a conference, do the following on each workstation:
Open a shell window, then type:
/usr/lib/InPerson/testmcast -s &
This command tells the system to start sending the test packets.
Log in to a system that is separated from your system by multicast routers. In a shell window, type:
/usr/lib/InPerson/testmcast
This command allows the system to receive a notifier when it receives a test packet from one of the other workstations. The notifier looks similar to the following message:
192.0.2.7 sent “xingping.widgets.com: Tue Sep 27 17:48:56 1994”
By default, testmcast uses a time-to-live (TTL) setting of 16. This means the test packets will pass through 16 routers. Use this default setting to verify that packets are being sent and received. To isolate a problem, try using a different setting on each system you want to communicate with in a conference:
Open a shell window, then type:
/usr/lib/InPerson/testmcast -st 1 &
This command tells the system to start sending the test packets. They will only pass through one router.
Log in to a system that is one router away. In the shell window, type:
/usr/lib/InPerson/testmcast
This command allows the system to receive a notifier when it receives a test packet from one of the other workstations.
If the system is able to receive the test packets, continue.
Cancel the command you started in step one, then restart it with a higher TTL setting on each system, each time logging in to a system one router away from the previous one.
For example:
After step three, log in to a system that is two routers away from the system you started on in step one. Type:
/usr/lib/InPerson/testmcast -st 2 &
Next, log in to a system that is three routers away from the system in step one. In that shell window, type:
/usr/lib/InPerson/testmcast
Check to see if that system received the test packets.
Continue this process until you find a problem.
The IRIX 4D1-5.3 version of the /etc/rpc file contains additions that are essential if you're running the Network Information Service (NIS). If the NIS master is not running IRIX 4D1-5.3 or a later release, or is not a Silicon Graphics workstation, verify that the /etc/rpc file on the NIS master includes these additions:
sgi_iphone 391010 sgi_videod 391011 |
If your system does not support video, you are automatically represented in conferences as a static image. You can also choose to use a static image for a particular call. “Creating a Custom Image” describes how to create the image and where to store it on your system.
InPerson can also use this image in one other instance. When you call someone, your image flashes on the phone as it rings. This occurs only if your image is accessible on the other user's system. One method to ensure that all users have access to face images is to store all the images a central database. InPerson can reference this database via NFS™.
To set up the database, the network administrator can do the following:
Select a system on which to store the images.
Create a new directory named /usr/local/lib/faces or /usr/lib/faces.
Copy each person's image into this directory. Make sure the filename matches the user's login name.
Give each user access to the directory by doing one of the following:
If people are running automount, have them make a symbolic link between this directory and a directory named /usr/lib/faces or /usr/local/lib/faces on their system. For example, if the database is in /usr/lib/faces on a system named ambrosia, the user becomes root, and then types:
ln -s /hosts/ambrosia/usr/lib/faces /usr/lib/faces
If people are not running automount, have them make an NFS mount to the directory. Choose “NFS Mount Manager” from the System toolchest, then follow the instructions in that tool's online help.
| Note: To find out if automount is enabled, open a shell window and type /sbin/chkconfig. Look for the word “automount” in the left column. If automount is enabled, the word “on” appears in the right column. |