Comrex ACCESS MultiRack Product Manual page 77

The challenges of connecting codecs behind NAT routers will be addressed in more detail shortly. For now,
remember that one of the problems NAT servers add is that private IP addresses delivered to codecs (and the
only addresses of which the codecs are aware) have no bearing on the public addresses seen from the Internet.
In extreme scenarios, several layers of address locality can be stacked, assuring that the IP address assigned to a
device is several degrees removed from the public IP address used for connections. Also, each address in the stack
is temporary and able to change at any time.
Before deployment of Switchboard, the answer to this dilemma was to assure that the codec located in the studio
had a fixed, public IP address. This meant that the address was allocated exclusively by the ISP, and that address
was entered manually into the configuration of the codec and not subject to change. This scenario worked because
IP "calls" are usually initiated from the field. As long as the field unit can find the fixed address of the studio unit
and send a stream to it, a reverse channel can be created easily and automatically by the studio unit, using the
source information contained in the incoming packets. In this scenario, the studio IP address must be memorized or
inputted into each codec individually.
The first function Switchboard works around is the dynamic IP address problem—by acting as a Directory Server.
Codec users simply log in to the free server and are given an Account, username, and password. Once logged in,
it's a simple process to input the details of each owned codec. On the codec itself, the user should input a familiar
name by which the codec will be known within that group.
Once enabled, a codec in a group that is physically connected to the Internet will sync with the server. The current
public IP address of the codec will be obtained by the server, and the user directory will be updated with the new IP
address. In addition, the availability status of the codec is also updated. The codec will "ping" the server if anything
changes (address, status, etc.). As we'll see, this "ping" function will prove useful in other ways.
Once the codec has updated its status with the server, it's time to download the directory. This process happens
instantly. The update includes current addresses and status info for all codecs within the group. This information
forms a "Buddy List" of sorts that gets integrated into the codec's connection address book. The list may still consist
of entries made manually by IP address into the codec, but those are signified by different icons. Current status of
each codec is reflected by graying out entries which are not currently connected or that haven't been synchronized
to the server.
If IP addresses change, the codec will re-sync with the server from the new address, and all will be updated
automatically. Connections can be made by simply clicking on the correct name, without any updating on the part
of the user.
The other roadblock provided by the use of NAT routers is the inability to accept unsolicited incoming connections
from the Internet. Generally, this function acts as a rudimentary firewall and is a net positive for security, but it
does cause headaches for codec users. A router that receives a connection request doesn't have a clue where to
forward that stream unless it has specific instructions programmed into it. These instructions are known as "port
forwarding."
This can work well for fixed installations, but it's not always an easy task to obtain that kind of security access on
corporate routers. Additionally, forwarding functions are implemented differently depending on the hardware. One
77