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:

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>1 ... <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.)


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 66666 63
Alternatively, the TCP connection (and command input) could be built directly into a client program.


Return to the main "liveGate for Intranets" page