Manual

70
Before deployment of Switchboard, the answer to this dilemma was to assure that the codec located in the studio has a
xed, public IP address. By xed, we mean that the address is allocated exclusively by the ISP, and that address is entered
manually into the conguraon of the codec and not subject to change. This scenario works because IP “calls” are usually
iniated from the eld. As long as the eld unit can nd the 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. Even in this scenario, the studio IP address must be memorized or input into each codec individually.
The rst funcon Switchboard works around is the dynamic IP address problem by acng as a Directory Server. Codec
users simply log in to the free server and are given an account name and password. Once logged in, it’s a simple process
to input the details of each codec owned. On the codec itself, the user will input a familiar name by which the codec will
be known within that group.
Once enabled, a codec in the 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 addion, 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” funcon will prove useful in other ways.
Once the codec has updated its status with the server, it’s me to download the directory. This process happens
instantly. The update includes current addresses and status info for all codecs within the group. This informaon forms
a sort of “Buddy List” that gets integrated into the codec’s connecon address book. The list may sll consist of entries
made manually by IP address into the codec, but those are signied by a dierent icon. Current status of each codec is
reected by graying out entries which are not currently connected or that haven’t been synchronized to the server.
If IP addresses should change, the codec will re-sync with the server from the new address, and all will be updated
automacally. Connecons can be made by simply clicking on the correct name, without any updang on the part of the
user.
The other roadblock provided by the use of NAT routers is the inability to accept unsolicited incoming connecons from
the Internet. Generally, this funcon acts as a rudimentary rewall and is a net posive for security, but it does cause
headaches for codec users.
A router that receives a connecon request doesn’t have a clue where to forward that stream unless it has specic
instrucons programmed into it. These instrucons are known as “port forwarding.”
This can work well for xed installaons, but it’s not always an easy task to obtain that kind of security access on
corporate routers. Also, forwarding funcons are implemented dierently on dierent hardware. You can easily imagine
the complicaons of obtaining or managing port forwarding on the LAN when arriving at a new remote venue. You would
likely encounter a large amount of resistance or confusion on the part of local IT sta.
In describing NAT roung, it’s important to understand the concept of ports. These are numbers, like the source and
desnaon IP addresses that are aached to each packet. They further qualify which applicaon on a computer (or
codec) is meant to send or receive a packet.