# Raider3D live: Raider3D conferencing

### Okyz Documentation Group

Copyright © 2003 by OKYZ

$Id: r3dconf-en.sgml,v 1.7 2004/02/17 08:38:30 dockes Exp $ (C) 2002 OKYZ

This document describes Raider3D conferencing general concepts and usage.

# 1. Introduction

## 1.1. Raider3D conferencing

The Raider3D live conferencing tool allows a group of people distributed anywhere on the Internet to share the same view of a Raider3D file. One member of the group is designated as the conference master, and all his moves are replicated on the other screens (slaves).

- At any time, a member of the group can ask and become the conference master.

- The conference tool has an integrated chat application which allows sharing text messages. Of course, it can also be used in conjunction with an audio conference call or another chat tool.

- The display systems can be vastly different in terms of resolution and performance. The update rate will automatically adapt to the capabilities of each client.

- Only visualization parameters data circulates during the conference. The data rate is very low (for example, a GSM phone link at 9600 bauds can be used quite comfortably).

- Conferences are hosted by server machines, which can be the free Okyz conference server, or a private server located on a customer network.

- The architecture is generally optimized to allow participation of clients located behind a firewall. The client can connect through an HTTP proxy.

- Any free Raider3D viewer can be a full conference member (which includes becoming a conference master).

- The capability to initiate (create) a conference requires the capture version of Raider3D and a specific conferencing license. Check the Okyz web site for more information about the conditions.

## 1.2. How it works: a quick explanation

Each of the clients participating in a Raider3D conference must have a copy of the same Raider3D (`.r3d`) file. As the conference software does not transmit any data, but only visualization parameters, this file must be sent to all attendees before the conference takes place (using E-mail, FTP transfers, web site access, etc ...).

To start the conference, the conference creator will load the `.r3d` file, possibly enter a conference password, and connect to the conference server (the conference will be destroyed as soon as the creator disconnects).

A hashed value derived from the file contents is transmitted as part of the connection data. This value must be the same for all members, which will ensure that everybody is working with the same file. The hash function is applied to the whole file, which means that even minor modifications to the file (like adding a view or annotation) will prevent joining the conference.

The role of the password value is to allow for distinct conferences using the same `.r3d` file simultaneously on the same server. The different meetings can be distinguished by using different passwords.

The triplet of (server, hash value, password) identify the conference you are connecting to. [1]

Even if it is relatively unlikely that several conferences using the exact same file will take place at the same time, using a password will prevent, for example, accidental sharing of chat messages.

Once the conference is started, the master conference client will send messages to the server each time its visualization parameters change. The server then sends the state changes to the other clients.

Having a central server allows for clients located behind a firewall, and unable to accept incoming connections.

## 1.3. Confidentiality and security issues

No encryption is used on the conference channels, on which 2 kinds of data are transferred:

- The visualization parameters.

- Chat and pseudonym data.

It is extremely unlikely that anything useful about the underlying object could be derived from the visualization parameters, which are mostly independent of the object. The only specific data are the measurement values, which are of little use without knowing what is being measured.

The likeliness that the chat text could be intercepted is small. But, as the communication channel is not encrypted, no secret information should be exchanged if you are dealing with sensitive issues (the confidentiality level is analog to the one for unencrypted E-mail).

A conference password should be used to protect against collision with another conference using the same file. Alternatively, you could modify the file before sharing it with the other conference members (for example: add an annotation).

## 1.4. Firewalls and proxies

Each Raider3D live client uses one TCP connection to the conference server.

The simplest way to enable Raider3D conferencing for the local network users is to allow outgoing connections to the Okyz conference server (currently live.okyz.com). The server indifferently listens on ports 80, 443, 3000. Attendees of a conference need not all use the same port. Other ports could easily be opened on request.

As live.okyz.com is a very secure Unix dedicated server and no sensitive data transits through it anyway (except possibly for chat text), this should not raise a security issue.

In cases where it is not possible to allow direct outgoing connections, the conference client can use an HTTP proxy to connect to the conference server. This uses the HTTP proxy CONNECT method, normally used by SSL connections. Raider3D supports the BASIC and DIGEST authentification methods (see RFC 2617, RFC 2817). The proprietary NTLM method is not supported for the moment.

As a last resort, if neither direct nor proxy connection to the Okyz server is compatible with the local security policy, it is also possible to run a conference server on an internal network host. Of course this supposes that all conference attendees can connect to this host, which may be plausible in some cases.

# 2. Using Raider3D live

The conference interface can be started from the File menu inside the Raider3D viewer. The Online collaboration entry will activate as soon as a file is loaded.

## 2.1. The "connection" section

Figure 1. The conference panel, connection tab

This section of the conference panel holds the connection parameters:

Host

  The conference host and port to be used should be entered here as `host``:``port`. This can be either the public Okyz conference server (`live.okyz.com:443`), or a private host. [1] [2]

Use HTTP proxy

  You should check this box if you are behind a firewall which won't allow direct connections to internet hosts, but allows you to access the WEB through a proxy machine. If in doubt, you can probably retrieve the appropriate information by checking the relevant section in your web browser setup. When the box is checked, the text area will activate and let you enter the name or address of the proxy machine.

Proxy port

  Port to be used for the connection to the proxy machine. If you are using a proxy, this parameter can probably also be found in your browser parameters. Else ask the system administrator.

Conference password

  All the members of a conference should enter the same value here. It is used to better ensure that two meetings using the same file will not collide. A blank password is acceptable if you think that a collision is very unlikely because the file has not been shared with other people.

Pseudo

  The value entered here will be used to identify you in chat messages and user lists. Choose a short but characteristic value

Connect/Disconnect

  Press the Connect button after entering the connection parameters to join an existing conference. The button label will change to Disconnect after the connection has occurred. If you are connecting through a proxy host and it requires user authentication, a user/password dialog window will pop up on connection.

Create

  This button will create a new conference for the currently loaded file. It will be active only if your Raider3D license allows you to create a conference. You will be automatically connected to the newly created conference.

## 2.2. The conference status section

Figure 2. The conference panel, conference status tab

This section of the conference panel holds the conference members interaction data and general status information.

Text display area

  In addition to chat text sent by conference members, miscellaneous messages about the conference state are displayed there.

Chat text entry area

  Type in there text that you want to broadcast to other conference members (the text is sent when you hit <CR>).

Send button

  Pressing this will send the text currently in the chat text entry field to the other conference members. It has the same effect as pressing the <CR> key in the text area.

Current users

  The current list of conference member pseudonyms is displayed there. The master member is marked with a small `m` before his name. The conference creator is marked with a small `c`.

Become Master

  This button allows you to request becoming the conference master (your moves will then be reflected to other conference members). Once you click the button, a window will pop up on the current master screen, requesting that he releases master status, which he can refuse to do.

# 3. Notes

### Notes

[1] | Ports: a Raider3D teleconference server will usually listen on different ports (80, 443, 3000 for `live.okyz.com`). In general, the clients of a given conference need not connect on the same port. The port value is not part of the rendez-vous data, and different ports are only used to make it easier to deal with different firewall policies.

[2]

If you are the conference creator, using a UNIX machine, and the host value that you enter is `localhost:``port`, the viewer will create a local server that can be used to host the conference. You should chose a high port value (like 3000) in this case, so that you don't need to be root to listen to the port. The other clients will be able to connect to `yourRealHostname:yourport`, if no firewall prevents it.