VoIP
From TCBWiki
Contents |
[edit] Overview
The TCB2 Units, TCB3 Family, and TCB4 Family all have VoIP capabilities. Using the Remote Control Interface (RCI), remote users can connect to the TCB units over a local area network or even the internet and participate in conversations via the RCI.
[edit] Troubleshooting
In an ideal world, any two devices connected to the same network would automatically be able to communicate. Unfortunately, in the real world things aren't that simple. Part of the reason for that is the need for security; you don't want anyone in the world with an Internet connection to be able to access your computer. To provide that security, we set up multiple levels of routers, firewalls, address translators, etc. All of those devices are typically set up to allow only specific types of network traffic that are considered safe, or at least too useful to be practically blocked. In some cases it is necessary to reconfigure those devices to allow the types of network traffic needed to make the TCB products communicate with computers.
[edit] LAN (Local Area Networks)
The simplest case is a LAN, or local area network. Typically on a LAN, all of the computers and other networked devices are connected to one or more switches and hubs. Each device has an IP address that can be used by other devices on the LAN to send information to it. These IP address often have the form 192.168.xxx.yyy, where yyy is unique for each device.
When a computer or TCB is installed in such a network, it needs a way to get a unique IP address. This is often done using a DHCP server. When the computer or TCB start up, they ask the DHCP server for an address, and it assigns one, taking care not to assign the same address to more than one device. There is no guarantee that each device will get the same address each time it starts up, although most DHCP servers attempt to keep the addresses the same (at least until the DHCP server itself gets reset, such as by a power bump).
When a TCB and computer are on the same LAN, it is typically quite easy to get them to communicate. The front panel interface of the TCB can be used to determine what IP address it is configured for (whether it was assigned manually or by a DHCP server). That IP address can then be entered into the RCI software, which will try to connect to the TCB. If it is able to connect, it will synchronize the data between RCI and the TCB so it can display the current configuration on the screen and it will allow RCI to change the settings on the TCB. If it does not work, see the Troubleshooting LAN TCP Problems section below.
[edit] Troubleshooting LAN TCP Problems
If you are unable to get RCI to connect with a TCB, even though both the computer and TCB are on the same LAN, try the following:
- Try using a serial cable between the computer and TCB, and telling RCI to connect using the serial port.
- Make sure that RCI is set up to connect to the correct IP address for the TCB. The TCB's IP address can be found using its front panel LCD or by watching the output on the serial port using a communications program like Hyperterminal (at 115K baud) as the TCB starts up.
- Open a command prompt and "ping" the TCB's IP address. An example would be "ping 192.168.1.34". If it times out, it indicates that there is not a valid network connection between them.
- If the above ping test is successful, turn the TCB off and ping its address from the computer again. It should time out. If it does not, it indicates that something else is on the same IP address. That will definitely cause problems, as each device on a LAN must have a unique IP address.
- Make sure the computer does not have firewall software that is blocking the network connection.
- Windows XP comes standard with firewall software. It can be disabled completely, or it can be configured to allow RCI to use the network connection. It will typically prompt you the first time a program attempts to use the network, asking if you want to allow it or not. You must allow RCI to use the network or it will not be able to connect with the TCB.
- If you have VLan (virtual LAN) or other advanced network software, you may need to contact your network administrator for help configuring it so it won't interfere with the connection to the TCB.
- If you have changed the network configuration for the computer or TCB, resetting them may be necessary before the new settings will take effect. You may also want to try cycling power to the network switch, hub, router or firewall.
- If the computer or TCB are configured to use DHCP to obtain an IP address and they get a different IP address each time they are restarted, or an IP address that doesn't begin with the same numbers as other addressses on the LAN (typically 192.168...), you may want to try manually assigning them IP addresses rather than relying on DHCP. Note that the IP address of both the computer and TCB will typically need to start with the same numbers, differing only in the last three digits. Before randomly choosing an IP address to try, ping it (as described above) to make sure that no other devices are using that address. If you have a network administrator, it would be best to ask for a static IP rather than choosing one randomly to avoid accidently choosing an address that is used by another device, which would cause an addressing conflict (and possibly a conflict between you and the network administrator :).
[edit] Using VoIP
From within the RCI software, it is also possible to enable VoIP (voice over IP) to allow the computer's speakers to be used to listen to audio from the TCB, and the computer's microphone to be used to send audio to the TCB. VoIP uses a different type of network packet than the connection described above, which sometimes causes additional problems (it uses UDP rather than TCP packets). If you are able to make a connection as described above, but are unable to get VoIP to work, try the following:
- From the Console | VoIP Settings menu:
- Make sure that the Enable VoIP Streaming checkbox is checked.
- If both the computer and TCB are on the same LAN, make sure that Connect via LAN is selected.
- Press the "Update" button in the lower-right corner of that dialog.
- If the cursor numbers do not change each time the "Update" button is pressed, it indicates that RCI is not receiving VoIP network data packets from the TCB. If this is the case, see the Troubleshooting LAN UDP Problems section below.
- If the cursor numbers do change, your computer is receiving VoIP packets. Clicking on a port that is receiving audio (the radio icon should be green) should allow you to hear that radio. If it is silent, make sure that in the Console menu, that the "On Port" selection is set for port 2 (the VoIP connection always uses port 2 with the current versions of firmware). If you still can't hear it, check that you can hear other audio through your computer's speakers (play an MP3 file, etc.).
[edit] Troubleshooting LAN UDP Problems
If the TCB and computer are on the same LAN and you can get them to communicate as described in the "LAN" section above, but you cannot get VoIP to work, there is probably something between the TCB and the RCI software that is blocking the special kind of network packets that are used for VoIP (UDP packets, rather than TCP packets - see the Firewalls/NAT section below for more details about that). If you are sure that your computer is not running firewall software that is blocking it, you may find it helpful to "look at" the data that your computer is receiving from the network to see if it is getting the VoIP data from the TCB. This can be done with a free program called WireShark (formerly EtherReal), as follows:
- Download WireShark from http://wireshark.org/ and install it.
- Run WireShark and select the Capture menu, then select Capture Interfaces. This will cause WireShark to display a list of the network interfaces on your computer and an indication of how much data is being transferred using each of them. If VoIP data is coming from the TCB to your computer, the "Packets/s" for your network interface should be at least 128, as that is how many VoIP packets the TCB sends each second (other network traffic may make that number higher at times, but is likely to be inconsistent). If you aren't getting that many packets/s, something is keeping the VoIP data from getting to your computer; that will have be be resolved before RCI can do anything with VoIP.
- If you are getting enough packets (as described above), but VoIP is still not working in RCI, you may want to get into the details of the network traffic. To do that, press the "Capture" button for your network interface in WireShark. That will show how much of each type of network packet is being received. VoIP packets are UDP, so you should see it count lots of those packets. Let it run a few seconds, then press Stop. WireShark will display a list of all of the network packets in the order they were transferred. The only ones you are interested in are UDP packets.
- If you find UDP packets coming from the address of the TCB to the address of your computer, the network is doing its job.
- If you go to the RCI menu labeled console and select VoIP Settings, then press the Update button in the lower right corner, the cursor numbers (current, last and fill) should change. If they do, VoIP is working.
- If WireShark shows that the UDP packets are getting to your computer, but RCI shows that the cursors are not changing:
- Make sure that you don't have two instances of RCI running. If you do, the other instance may be capturing the network traffic (as well as the sound card).
- Check your Windows firewall and network settings again. If WireShark shows that packets getting to your computer but RCI isn't receiving them, there must be something in the middle blocking them.
Note that WireShark will show only the network traffic that is on the cable connected to your computer. If all of the devices are connected together using a hub, this will be all of the traffic on your LAN. In recent years, hubs have become less common, being replaced by switches. Switches improve the throughput of your network by not sending all of the traffic to all of the devices on the network, instead often sending data only to the device it is destined for. Because of this, if your computer is connected using a switch, WireShark will be only able to display information about network traffic that is coming to or from your computer, not traffic between other devices on the network.
One method of troubleshooting with Wireshark is to unhook the network cable from the TCB, plug it into a hub (not a switch), then plug another cable from the hub into the TCB. That should allow it to communicate with the rest of the network again, but with a hub in the middle. A computer running WireShark can then be connected to the hub. That will allow the computer to see all of the network traffic to and from the TCB. Either that computer or any other computer on the network can run RCI to generate traffic for WireShark to monitor.
[edit] Firewalls/NAT
When the TCB and the computer running RCI are not on the same LAN (such if the connection is being made over an Internet connection), the data is likely to have to pass through one or more routers or firewalls. Some of these use a technique called NAT (network address translation) to provide security for the devices on the LAN behind the firewall.
When running RCI behind a firewall that uses NAT (Network Address Translation) and connecting to a TCB that is outside the firewall, it is common to have trouble getting VoIP to work. VoIP is more problematic that just getting a Telnet data connection, because VoIP packets don't pass through a firewall as easily. That is because Telnet uses the TCP/IP protocol, which is "connection oriented" while VoIP uses UDP, which is "connectionless". Without getting into the details, firewalls have an easier time with Telnet because when RCI makes a TCP/IP connection, it creates a two-way path through the firewall, allowing data to flow in both directions.
VoIP, on the other hand, sends each data/voice packet as a separate entity, with just a destination IP address to control where it goes. It isn't typically a problem for a device behind a firewall (like a PC running RCI) to send UDP packets to device outside the firewall (like a TCB on a static IP address). Getting data/voice packets back from the TCB, through the firewall, and back to the PC is often difficult. This is because the NAT features of the firewall hides the IP address of the PC; that is one of the ways it provides security. The hidden address often begins with 192.168..., which indicates that it is a private address that couldn't be routed over the Internet even if the firewall didn't hide it.
So how does any data, even TCP/IP data, get from the TCB to the PC? When the PC makes a TCP/IP connection through the firewall to the TCB, the firewall sets up a "connection", translates the PC's private address to the firewall's address (which is visible from outside), then forwards the data to the TCB. The TCB sends data back to the firewall's address, where the firewall looks up the "connection" information and finds that it needs to forward the data to the PC's hidden address. The TCB never has to know what the PC's address is because the firewall takes care of the translation and forwarding the data.
To get VoIP data from the TCB to the PC, we need the firewall to do the same thing.
!!!!Unfortunately, because VoIP uses UDP and UDP is "connectionless", it doesn't happen automatically. When the PC sends packets to the TCB, the firewall forwards them, but does not translate the "from" address (I could be mistaken about that) nor keep track of the return path. The TCB has to be set up to send VoIP packets not to the "LAN" address of the PC (the private address it has behind the firewall), but to the address of the firewall itself. Then the firewall has to be manually configured to send that data to the correct PC. !!!!
Usually a systems administrator will need to do that, because it involves changing the firewall's security settings. Fortunately, getting VoIP to work with the TCB requires opening forwarding only a very specific type of data/voice packet from a specific address, so the security risk is very small. (A future version of the TCB software may provide an automatic way to get the VoIP data through the firewall, making manual reconfiguration of the firewall unnecessary).
The exact process varies between firewalls, but generally involves setting up "port forwarding" (sometimes called "packet filtering"). Packets from the TCB's address and port 23000 (the port used for VoIP data/voice packets) need to be forwarded from the firewall's IP address to the PC's internal address. http://portforward.com/routers.htm provides information about how to set up port forwarding for many types of routers.
Even after getting port forwarding set up, some firewalls see all of the data coming from the TCB (about 128 packets per second) and think that they are getting hit with a flood attack (from a hacker trying to crash the system), and discard the packets rather than forwarding them. This should show up in the firewall's log. On the CyberGuard SG560, the solution is to set up a destination NAT rule to specify that packets from the TCB's IP address to the PC's local IP address should be translated (very similar to the port forwarding rule). As of 2009, some consumer routers are also starting to implement "DOS" (denial of service) protection which incorrectly blocks the VoIP packets. On at least one model of Linksys VPN router, disabling the DOS feature is a workaround.
If that doesn't work, it might be possible to get more information about what the firewall is doing by opening a telnet connection to it and running "tcpdump" at the command line.
We haven't tested it, but <http://www.portforward.com/> might be a good resource for information about how to set up port forwarding on your router.
