Appendix B

Technical Issues

Overview

This appendix provides more detailed, technical information about Communique! and hardware components. This information is provided to help you, the advanced administrator, solve problems related to Communique! and to enable you to take advantage of some of Communique!'s more advanced features.

The FLEXlm Licensing System

MDL employs version 3.0 of Globetrotter Software’s Flexible License Manager (FLEXlm) for license key management. FLEXlm allows for both node-locked and floating software licenses. Floating licenses enable users to make more efficient use of fewer licenses by sharing among several systems.

The four main components of licensing are

The License Manager daemon (lmgrd) is in charge of starting the vendor daemon (insoftd) and handling initial contact with the software. There is a daemon running for each vendor who has a FLEXlm licensed product on the network. The vendor daemon keeps track of how many licenses are checked out, verifies encryption codes, and checks expiration dates. The software communicates with the MDL’s vendor daemon (insoftd) to verify licensing before proceeding. The vendor daemon checks to see if any licenses are available and then accepts or denies the request.

Starting/Stopping the License Manager

Normally, the License Manager daemon is started during the boot process in either the /etc/init.d/lmgrd or /etc/rc.OpenDVELicense script, depending on your platform. The License Manager uses the license file specified by the -c switch. The license file is read into memory when the daemon is initialized. To incorporate changes made to the license.dat file, you must stop and restart the License Manager daemon.

To stop the daemon, you should use the lmdown utility, which is located in OPENDVE_HOME/bin. The lmdown utility allows the lmgrd and insoftd processes to exit gracefully.

Note that shutting down the license server will cause users of all FLEXlm licensed products to lose their licenses.

To start the daemon, either reboot or run the appropriate boot script manually.

The License File

The licensing daemon obtains all of the licensing information from the license file. By default, the license.dat file will be created in the etc/insoft directory; however, the default setting can be changed during installation. The license.dat file contains one SERVER line, one DAEMON line per vendor, and multiple FEATURE lines.

The SERVER Line

SERVER nodename hostid port-number

SERVER lines specify the host that will be acting as the License Server. The id is the workstation’s hostid (not hostname). The port number 5150 is determined by MDL, and normally should not be changed. An example of a typical SERVER line is show below:

SERVER lonestar 80325305 5150

The DAEMON Line

DAEMON daemon-name path options

The DAEMON line specifies the vendor daemon to be used. The path should be the full path and filename of the daemon. The available options are described in Globetrotter’s FLEXlm End User Manual. A typical DAEMON is shown below.

DAEMON insoftd /opt/insoft/opendve/bin/<arch>/insoftd

where <arch> specifies your machine's architecture; one of: solaris, Irix, hpux10, axp, or aix.

The FEATURE Lines

FEATURE name daemon version expdate number code "vendor string" hostid

Each FEATURE line specifies licensing information for an available feature that may be requested by the MDL software. Currently the following features are supported:

opendve.engine—allows the user to run the ISconferenceEngine process. The ISconferenceEngine is essential for using OpenDVE applications like Communique!. Each user running Communique! requires an opendve.engine license.

opendve.plugin—allows the user to run Plugins. Each Plugin loaded requires a specific number of opendve.plugin licenses in order to run. For example, if a user does not load the TV Tool, then fewer licenses are required to run Communique!. Some Plugins will require their own special license (i.e. MDL SHARE).

opendve.share—allows the user to run MDL's SHARE Plugin. SHARE provides application sharing among conference members. With SHARE conference members can work together on most X-based applications. SHARE is an optional feature that may be purchased from MDL.

opendve.imager—allows the user to run MDL’s Shared Imager Plugin. The Shared Imager is a collaborative imaging tool that supports 24-bit color displays. It also allows users to create and present slide shows to other conference members. The Shared Imager is an optional feature that may be purchased from MDL.

opendve.remote—allows the user to run the Remote Control Camera Tool, which enables users to control Canon VCCI cameras from within Communique!. With this tool users can position their camera, or the camera of any other conference members who are using a Canon VCCI.

The version specifies the version of the vender daemon, not of the application software. Communique! 4.X uses version 4.000 of the insoft vendor daemon. Do not change this value.

MDL does not use the vendor field. The string field should be set to an empty string, "".

The trailing hostid is used only if the license is node-locked. A typical FEATURE line is shown below.

FEATURE opendve.engine insoftd 4.000 01-jan-00 1 BB6C3264DA440D48848F "" 80123405

Trailing hostids are not used for floating licenses.

Using MDL Software with Other FLEXlm Licensed Products

If you have other products that use the FLEXlm license management system at your site, you may wish to merge your license files together. By combining your licenses you will have only one license.dat file and one lmgrd process running on a central server. This is not a requirement, because you could run multiple lmgrd processes on the same node, each serving licenses for a particular product or group of products.

You can also set the LM_LICENSE_FILE variable to point to several files if you wish to use more than one FLEXlm licensed file at the same time. For example:

setenv LM_LICENSE_FILE/etc/insoft/license.dat: /opt/other_app/license.dat:/opt/etc/license.dat

If you want to run only one License Server, there are several factors to consider:

1. Each license.dat file should have only one SERVER line, unless you are running redundant servers.

2. Each FEATURE line lists a vendor daemon which it uses to communicate with the vendor’s products. MDL’s daemon is called insoftd. You should include a DAEMON line for insoftd.

3. The path to the MDL daemon, as listed on the DAEMON line, must be accessible to the License Server.

4. MDL currently uses version 3.0 of the FLEXlm licensing product. Other releases of the lmgrd daemon will not function correctly with MDL products.

If you need more information about the FLEXlm licensing system, the FLEXlm End User Manual is available from Globetrotter Software, (408) 255-5616.

The Role of the OpenDVE Architecture

MDL's Communique! has been developed with MDL's OpenDVE architecture, a productive application programming environment for collaborative applications. Using this environment, application providers can efficiently accomplish the following:

Create customized collaborative environments with the appropriate access and membership policies.

Add collaborative features to specialized applications.

Incorporate distributed multimedia functions into their applications.

Exploit the latest state-of-the-art audio, video, and network technologies.

Develop interoperable products targeted to several architectures and multiple network technologies.

Enable open collaborative applications as opposed to vendor-specific access-only APIs.

For more information on the OpenDVE Architecture or to receive a copy of our technical white paper, contact MDL at 425-861-6700 or send e-mail to sales @ mdlcorp.com.

OpenDVE Plugins

One of the benefits of working with OpenDVE is the ability to create Plugin applications. These Plugins are unique applications or enhancements that extend the capability of a product through the OpenDVE architecture. Plugins can be created in-house with the OpenDVE API. All Plugins can take full advantage of OpenDVE's multiplatform collaboration and conferencing functions.

Plugin Names

All OpenDVE Plugins follow a standard naming convention. It is helpful to understand how this convention works. The format for an OpenDVE Plugin is as follows:

<VendorID><Function>Plugin<Hardware><WindowManager>

VendorID—the short vendor identifier for the company developing the Plugin. For MDL, this identifier is "IS".

Function— this is a short description of the functionality of the Plugin. Examples are Whiteboard, TextTool, VideoTool.

Plugin—this denotes that the executable is an OpenDVE Plugin. This is a literal value.

Hardware—this is the hardware dependency of the Plugin, if this Plugin requires different executables for similar functionality due to hardware dependencies. Examples are

ISVideoToolPluginParallaxMotif

ISVideoToolPluginSunVideoMotif

Window Manager—this denotes the Window Manager used for this Plugin. The choices are:

OL—OpenLook (XView) Based Plugin
Motif—Motif Based Plugin
Raw—Non-Window Manager Based Plugin

An example of this naming convention for the MDL Whiteboard:

ISWhiteBoardPluginMotif

VendorID = IS (MDL)
Function = WhiteBoard
Hardware = none
WindowManager = Motif

Communique!'s Plugins

Most of the Communique! executables are Plugins and are found in the plugin/ directory in the Communique!'s installation directory. Each Tool that you can access from the Conference Manager, and indeed the Conference Manager itself, are Plugins. These Plugins are discreet programs which interoperate through the OpenDVE architecture. Each Plugin is stored in its own directory. Most of the Plugins and libraries used by Communique! support multiple architectures. Libraries and executables that are architecture dependent are referenced according to the following conventions:

aix—IBM AIX

axp—Digital Alpha Digital UNIX

hpux10—Hewlett Packard HP-UX 10.xx and later

sol25—Sun Solaris 2.5.1 and later

irix—SGI Irix 5.3

IP Multicast and the TTL Value

Multicast is a networking technology that reduces duplication of network data in multipoint conferences. If you are using Unicast routing, a separate stream of data is sent to each user receiving video or audio. This means that in a 4-way conference in which everyone is sending audio and video, there are 12 audio and video streams being sent, 3 per user. Multicast enables Communique! to send out only one stream of video data and one stream of audio data regardless of the number of users receiving the data. If the same group of users described earlier were using multicast routing, there would be only 4 audio and video streams total for the conference, greatly reducing the amount of network bandwidth usage, and freeing up resources on the machines that are sending data.

Multicast packets are received only by workstations interested in the packets. This "packet filtering" is done in low-level hardware, not by the CPU.

For multicast to function correctly, an explicit route to the multicast address must be defined so that the workstation will recognize it as a valid local address. The multicast address is normally 224.0.0.0. The route is normally added to /etc/rc.local during installation, and is done with the following command:

Route add "224.0.0.0" hostname 0

You will also want to make sure that all of your network hardware includes support for multicast routing. If you will be conferencing with users across a router, you will need to make sure that the router supports multicast.

You can find out if your network interface supports multicast using the ifconfig command. For example, to see if multicast was supported on an HP-UX 10.20 machine, you would type:

ifconfig lan0

Time To Live (TTL) is an attribute of IP multicast that defines how far a multicast packet travels out across the network. Each time a multicast packet travels through a gateway its TTL value is decremented by 1. Some gateways may decrement the TTL value by 2, 3, or more to control the distribution of multicast packets. Although there are no set standards for TTL values, there are a few conventions that have been established:

1 Restrict the packets to the local subnet

32 Restrict the packets to the site

64 Restrict the packets to the region

128 Restrict the packets to the continent

256 Do not restrict the packet’s travel at all

You will want to use the lowest TTL possible to avoid wasting bandwidth on uninterested segments of your network.

Using Multicast with Communique!

If you want to use multicast routing with Communique!, you will need to enable it in the appropriate Communique! setup files. In either individual configuration files, found in each user’s CommuniqueSave directory, or in the global defaults files, found in the individual directories of each plugin, you can enable multicast.

In order to enable multicast, you should make the following changes:

In the ISTVToolControlPanel.ini file you should add the following entry under the [Networking] heading:

DoMulticast = 1

In the ISAudioToolControlPanelPlugin.ini file, you should add the following entry under the [Networking] heading:

DoMulticast = 1

If these entries already exist, you can change the values from 0 to 1 to enable multicast.

Customizing Communique!

Communique! can be custom-configured to fit the needs of your installation through its configuration files. Each Plugin used by Communique! has its own configuration file, usually the Plugin name with the extension .ini. These configuration files control, to some degree, the behavior of the Plugin. Any user-configurable options associated with the Plugin (playback volume in the Audio Tool for example) are stored in the configuration file. Some Plugins have other information stored in their configuration file that controls the options and behavior of the tool. These options not only open Communique! to customization, but also make it extremely receptive to supporting new hardware as it becomes available. All of these can be manually changed to fit the needs of your installation. Each Plugin can have three different configuration files: a global defaults file, a user preferences file, and a locked global defaults file. The TV Tool can also have a system defaults file that defines hardware options specific to its host.

Detailed information on the contents of the various .ini files that Communique! uses can be found in Appendix C, Communique! .ini Files.

Global Defaults Files

Each Plugin has a default configuration file stored in the Plugin's home directory, which is normally in plugins/ in Communique!'s install directory. These files serve as the global defaults for the Plugin.

User Preferences Files

Each time a Plugin is used, a subset of its configuration file is stored in the home directory of the user running the Plugin. The file is stored in the CommuniqueSave directory which is created automatically the first time the user runs Communique!. The CommuniqueSave directory contains user preferences files for every Plugin used. These files generally contain only those preferences directly modifiable through the interface such as frame speed, color settings, etc. The settings in these local files override the settings defined in the Plugins' default configuration files.

Locked Global Defaults Files

Locked global defaults files define options of the configuration files that cannot be overridden by the user preferences or regular global defaults files. Locked global defaults files are created by creating a subset of a Plugin's configuration file with the extension _locked in the same directory as the standard global defaults file. Any settings defined here override both the standard global defaults file and any user preferences file. An example of a locked global defaults file is:

ISAudioToolControlPluginMotif.ini_locked

System Defaults Files

Locked system defaults files define hardware specific options of the configuration files that cannot be overridden by any of the other defaults files. The locked system defaults files are stored in the /etc/insoft directory, meaning they are specific to one host instead of the entire Communique! distribution. Currently only the TV Tool supports a system defaults file. The TV Tool's system defaults file is:

/etc/insoft/ISTVToolControlPanelPlugin.ini

By placing a subset of the TV Tool's global defaults in this file and removing entries for video cards not installed on the workstation, you can eliminate invalid TV Tool video cards selections. For example, assume that one of your workstations is a Sun running Solaris 2 and has only a Parallax card installed. The global factory defaults file for the TV Tool (as shipped) would contain the following entry for Solaris 2.5.1:

[sol25]

NumBoards = 2

Board0 = SunVideo

Board1 = Parallax

NumFormats = 2

Format0 = ICLB

Format1 = J422

If you want to remove the SunVideo selection from the TV Tool then reduce the NumBoards parameter to 1 and redefine Board0 (actually the first card) to be the Parallax card. It is not necessary to include options other than those you have changed.

[sol25]

NumBoards = 1

Board0 = Parallax

Because many of the tools require the information stored in the global configuration files to operate, modifying configuration files is inherently dangerous. Please make a backup copy of the original configuration file before attempting any modifications.

Audio on Remote Workstations or X-Servers

By default the Audio Tool will not start if you are running on a remote X-Display or X-Server since such configurations would not generally provide audio capabilities. This behavior can be overridden by setting the "Permit Remote Audio" flag in the Audio Tool's .ini file to "true".

Broadcast Tunneling

If you often conference with users who are not on your local network or subnet, you can use broadcast tunneling to locate them automatically. When you try to create a conference, the Start Conference control panel sends a broadcast message looking for other Communique! users. If you wish to detect users outside of your local network, you must create the file /etc/insoft/tunnels on one of the workstations on your network. In this file, list the IP numbers of specific workstations or the broadcast addresses of networks outside the local network that you wish to scan for Communique! users.

When a broadcast message is received by Communique!, it responds to the query and forwards the request to the IP addresses specified in the /etc/insoft/tunnels file. Lines in this file that begin with a semicolon are processed as comments. For example, if you are on the network 192.9.200.0 and you often conference with machines on a network with a broadcast address of 204.20.150.0 and a workstation whose IP is 127.193.14.31, then your file would be:

; sample /etc/insoft/tunnels file

;

; the development net

204.20.150.0

;

; John’s machine only - not everyone on his subnet

127.193.14.31

Multiple Interfaces

If you have more than one network interface configured on your machine, Communique! will always pick the first one started upon boot time unless you specify the interface. To do this, you should create a file called interfaces in the directory /etc/insoft/ and enter the hostnames or IP addresses of the interfaces on your machine in order of preference, with the first hostname in the file denoting your first choice of which interface to use. This will ensure that when Communique! is started, it will register itself on that interface regardless of the order that the multiple interfaces are started at boot time.

The Corporate Notebook

The Corporate Notebook is a system-wide Notebook file that allows all of the Communique! users in your organization to access a common list of potential conference members. The Corporate Notebook can be used to easily store the user addresses of all of the people in your organization by their real name, and to create logical groups of users for people to invite into conferences.

The Corporate Notebook should be stored on a partition that is accessible by the entire organization, or a copy should be stored in a common location on all of the machines that will run Communique!. The default location for the Corporate Notebook is in $COMM_HOME/etc/notebook.ini.

There are two ways that one can create or edit the Corporate Notebook file. The first is for the administrator to edit their personal Notebook using the Notebook Editor to reflect the entries that should be in the Corporate Notebook. Then copy that notebook.ini file to the location where the Corporate Notebook will be stored.

The second way to create the Corporate Notebook is to edit the entries in it by hand using a popular editor, such as vi or emacs. The format that notebook entries take follows:

[Group: <group-name>]

Member# = <user>@<host> [, IPA: <host IP address>]

Member# = <group-name 2>

The Group field contains the name of the group, which will be listed in the list of groups that can be invited to conference. The member fields can either contain usernames and hostnames, or names of other groups that have been defined, for example:

[Group: East Pennsylvania]

Member1 = ellie@perch.insoft.com, IPA: 192.9.200.13

Member2 = christie@snapper.insoft.com, IPA: 192.9.200.142

Member3 = bruce@wizard.insoft.com

 

[Group: West Texas]

Member1 = denzin@salmon.insoft.com

Member2 = vona@bigdog.insoft.com, IPA 192.9.235.131

Member3 = anup@sparcy.insoft.com

 

[Group: Everyone]

Member1 = East Pennsylvania

Member2 = West Texas

Member3 = beth@mudbug.insoft.com

Note that groups and users can be mixed together in a single group. Also note that the IP address for a member’s host is optional. Groups can also contain only one member for aliasing purposes, for example:

[Group: Rafe Colburn]

Member1 = rec@ywfn.insoft.com

Using these conventions, you can create and edit your Corporate Notebook file.

Regulating OpenDVE Port Usage

You can specify the ports that OpenDVE will use by adding entries to your /etc/services file. In doing so, you can insure that there will be no conflicts between Communique! and other networking applications as far as port usage goes.

To specify the port that basic OpenDVE communications will occur on, add the following line to your /etc/services file:

opendve <port number>

The port usage of the OpenDVE Locator, which searches for other OpenDVE clients on your network, can also be regulated. To set the port that it will use, add the following line to your /etc/services file:

opendve-locator <port number>/udp

You can also specify the range of ports that will be used by the Audio Tool and the TV Tool. Both the Audio Tool and TV Tool select a port to use from an allotted range, so you will need to enter maximums and minimums for their port numbers as follows:

For multicast audio:

opendve_audio_mcast_min <lowest port number>/udp opendve_audio_mcast_max <highest port number>/udp

For unicast audio:

opendve_audio_unicast_min <lowest port number>/udp opendve_audio_unicast_max <highest port number>/udp

For multicast video:

opendve_video_mcast_min <lowest port number>/udp opendve_video_mcast_max <highest port number>/udp

For unicast video:

opendve_video_unicast_min <lowest port number>/udp opendve_video_unicast_max <highest port number>/udp

The default port numbers used by OpenDVE are as follows:

opendve 6550

opendve-locator 6499

 

opendve_audio_mcast_min 50000/udp

opendve_audio_mcast_max 50000/udp

 

opendve_audio_unicast_min 50000/udp

opendve_audio_unicast_max 50000/udp

 

opendve_video_mcast_min 50000/udp

opendve_video_mcast_max 50000/udp

 

opendve_video_unicast_min 50000/udp

opendve_video_unicast_max 50000/udp

Internationalization

MDL is working to internationalize Communique!. Internationalization (I18N) is the process of writing applications that can be easily adapted to specific locales or languages without changes to the code. I18N enables users to incorporate custom message catalogs into Communique!, so that the interface is understandable to non-English reading users. The message catalog is a database of the message text displayed by an application.

In order to set up a user’s environment to take advantage of internationalized features provided by Communique!, you should do the following:

1. Set the LC_ALL variable to the current language. If this is not set, the default locale (the C locale) will be used.

2. Set the NLSPATH variable to point to the correct message catalog. If this is not set properly, then the default message catalog will be used.

Ordinarily, message catalogs are located in the directory:

$COMM_HOME/lib/nls/<language>/<OS_Type>

In order to take advantage if I18N for a particular language, a message catalog for that locale is required.

You will also need to make sure that there is an appropriate font list defined for the application, in this case the Text Tool.

One way to specify these fonts is for each user to include them in their .Xdefaults file. The font list should be specified in the .Xdefaults file as follows:

ISTextToolPluginMotif*fontList: <font_name>; \

<font_name>; \

<font_name>:

If you want to change the font list for all of the Communique! users, you should edit the file:

ISConferenceManagerPluginMotif

In $COMM_HOME/lib/app-defaults/<OS_type> to include the fonts necessary to print text for your locale. To do so, you should add the information in the example listed above to this file, under the "Defaults for all Plugins" heading.

Currently, the Text Tool supports internationalized message catalogs.

Return to MDL Home Page