Comrex BRIC-Link II, Product Manual

Page: 65 / 104

on ini al connec on. That address is “leased” from the server for a par cular me period, and a er the “lease”
expires, the server is free to change it.
The commonly used Network Address Transla on (NAT) router adds to the confusion, making codecs even harder
to
fi nd. Most Local Area Network (LAN)-based Internet connec ons (as opposed to computers connected directly to
ISPs) actually nego ate with a local router containing its own DHCP server. This router assigns the LAN computer or
device a “private” IP address for iden
fi ca on within the local network .
The challenges of connec ng 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 connec ons (as illustrated in
Figure 56 ) .
Addi onally, each address in the stack is o en temporary and able to change at any me.
Before deployment of Switchboard, the answer to this dilemma was to assure that the codec located in the studio
had a
fi xed, public IP address. This meant that the address was allocated exclusively by the ISP, and that address
was entered manually into the con fi gura on of the codec and not subject to change. This scenario worked because
IP “calls” are usually ini ated from the fi eld. As long as the fi eld unit can fi nd the fi xed address of the studio unit
and send a stream to it, a reverse channel can be created easily and automa cally by the studio unit, using the
source informa on contained in the incoming packets. In this scenario, the studio IP address must be memorized or
input into each codec individually.
The fi rst func on Switchboard works around is the dynamic IP address problem by ac ng as a Directory Server.
Similar to a DNS, this Directory Server func on stores real IP addresses and translates them into user-friendly
names, but on a much smaller scale that is only relevant to Comrex codecs. Codec users can name their codecs and
use those names to establish connec ons, rather than using IP addresses. The codecs themselves need only know
the public IP address of the Switchboard server, and that server provides them with the more elusive IP addresses