Configuring "liveGate for Intranets"

It is assumed that you are already familiar with configuring a (regular) "liveGate" server. If, as is usually the case, such a server is acting as the remote end of a tunnel from "liveGate for Intranets", then that server must configure a tunnel in the usual way.

As with "liveGate", "liveGate for Intranets" is configured using a file - in the same directory - named "liveGateInit". Each tunnel is also specified in the usual way, using the liveGate_createTunnel command. (If "liveGate for Intranets" is being used for firewall traversal, then you will usually need only one such tunnel.)

A reminder: You cannot create a tunnel between a pair of "liveGate" servers, nor between a pair of "liveGate for Intranets" servers. Instead, you must run "liveGate" at one end of the tunnel, and "liveGate for Intranets" (a different binary) at the other end. Because "liveGate for Intranets" controls the tunnel, it should be run on whichever side of the tunnel is considered more secure.

Note also that the special commands ("liveGate_startRelaying", etc.) described on this page are applicable only to "liveGate for Intranets".

Starting (and stopping) multicast relaying

"liveGate for Intranets" adds extra commands for controlling the relaying of specific multicast addresses/ports. These commands must be executed after all tunnels have been created.

Important note: For "liveGate for Intranets", your "liveGateInit" file must contain at least one "liveGate_startRelaying..." command (as described below). Just setting up a tunnel to a remote ("liveGate") tunnel endpoint is not enough; you must also tell "liveGate for Intranets" which multicast address(es) and port(s) you wish to relay.

liveGate_startRelaying <multicast address> <port> <ttl> <tag>

This command turns on the relaying - across each tunnel - of packets sent to the specified multicast address and port. (<multicast address> must be in 'dotted quad' form.) The <ttl> parameter specifies the TTL that tuneled multicast packets will be given when they're re-multicast on the internal network.

Note: In this version of "liveGate for Intranets", this same TTL will also be given to outgoing packets (i.e., on the external Multicast Internet), regardless of the actual TTL that appeared in the incoming packet (i.e., when it arrived over the internal network). Therefore, you should be careful when relaying sessions that have internally-generated packets with varying TTLs - for instance, SDP/SAP announcements. A future version of "liveGate for Intranets" may notice the TTL of incoming (local) multicast packets, and use it in each corresponding outgoing packet. (The price for this is that this future version of "liveGate for Intranets" would have to run as 'root'.)

<tag> - optional - is a user-chosen human-readable name for this session. This can later be used to turn off relaying for the session (using the liveGate_stopRelayingByTag command).

The following additional commands are useful for dynamic control:

```
liveGate_stopRelaying <multicast address> <port>
```
This command turns off any relaying of the specified multicast address and port.
```
liveGate_stopRelayingByTag <tag>
```
This command turns off relaying of any sessions that had been started with the specified tag.
```
liveGate_listRelayedSessions
```
This command returns a list describing each the sessions that are currently being relayed. Each session is described as follows:
```
{<multicast address> <port> <ttl> <tag>}
```
where <tag> is the tag that was specified in the call to liveGate_startRelaying (or {} if no tag was specified).

Relaying RTP/RTCP sessions

If a RTP/RTCP session is to be relayed, then this must be done for two ports: the RTP (even) port, and the RTCP (odd) port. Although you can do this by calling liveGate_startRelaying twice - once for each port - a better way is to use a special command:

liveGate_startRelayingRTP <multicast address> <even port> <ttl> <tag>

To stop relaying a RTP/RTCP session, call:

liveGate_stopRelayingRTP <multicast address> <even port>

Relaying "source-specific multicast" ("SSM") sessions

To relay remote multicast traffic that originates only from a specific source address, you can use the following command:

liveGate_startRelayingSSM <multicast address> <source address> <port> <ttl> <tag>

This command instructs the remote end of the tunnel to send you multicast data that was addressed to <multicast address>, but only if the original source address was <source address>. (Note that because UDP-level tunneling is used, when "liveGateForIntranets" re-multicasts this data, the source address will change. Therefore, receivers should either do a regular (non-SSM) multicast join, or a SSM join to the new source address - that of the "liveGateForIntranets" node.)

There are also three other SSM relaying commands, analogous to their non-SSM counterparts:

liveGate_stopRelayingSSM <multicast address> <source address> <port>
liveGate_startRelayingRTPSSM <multicast address> <source address> <port> <ttl> <tag>
liveGate_stopRelayingRTPSSM <multicast address> <source address> <port>

Dynamically controlling multicast relaying

The above commands can also be used to start/stop relaying dynamically - e.g., on demand. There are two possible ways to do this. First, recall that the "liveGateInit" file can contain any valid script in the Tcl scripting language. If you're familiar with this language, you may use it - in combination with the above commands - to write a program that does relaying any way you choose.

An alternative (and easier) way to dynamically control relaying is to use a built-in TCP 'remote control' mechanism:

liveGate_createRemoteControl <port> <client>₁ ... <client>_n

This command configures the server so that it can accept TCP connections, on the specified port, for executing commands. Each <client> - if present - is the IP source address of a client machine that is permitted to connect to the server. (If no <client>s are specified, then any client machine is permitted to connect.)

Example

Suppose that the "liveGateInit" file contains, after the creation of one or more tunnels, the following command:

liveGate_createRemoteControl 8888

You could then connect to the server by running:

telnet <the "liveGate for Intranets" server> 8888

and then typing commands, e.g.:

liveGate_startRelaying 224.44.44.44 66666 63

Alternatively, the TCP connection (and command input) could be built directly into a client program.

Notes:

Any command (script) that can appear in the "liveGateInit" file can also be executed using a remote control TCP connection.

A remote control client can use a special command quit to close its TCP connection. (The standard Tcl command exit can also be used, but this will shut down the entire server.)

If a client program also uses Tcl, then it can easily create TCP connections and invoke commands by using Tcl's socket, puts, and flush commands. (There is, of course, absolutely no requirement that a remote control client use Tcl; it can create and write its TCP connection however it chooses.)

Return to the main "liveGate for Intranets" page