Linking gateways using VoIP

From TCBWiki
Jump to: navigation, search

The information on this page is relevant for the TCB-IP2 and MSAT-IP gateways. For information about the TCB2, TCB3 or TCB4, instead see How do I use VoIP to link two TCBs?. Also see VoIP.



The gateways have two to four physical radio ports (interfaces to real radios) and eight "virtual radio ports". Each virtual radio port is treated by the controller's software as if it were a real radio, with its own IDs, timers, etc. Since there is no way to directly connect such a virtual radio port to a physical radio, they are instead used to "transmit" and "receive" by sending audio data over an Ethernet (TCP/IP) network; this is called VoIP (Voice over IP) or RoIP (Radio over IP). This allows the virtual ports to be used to link gateways (or other compatible devices) in a manner very similar to using traditional radios to create links between radio sites, but using a network rather than link radios.

Setting up the network

To make gateways communicate over a network, their Ethernet connectors need to be connected to each other either directly or indirectly (possibly even over a wireless network or the Internet). There are several ways this can be done:

  • The easiest is to plug the controllers into a router such as the ones typically used to provide Internet access in a home or office. Typical brands are Linksys, D-Link and Netgear. Many of these routers have four or so Ethernet jacks built into them (use the ones labeled "LAN", not "WAN"). Just plug each controller into one of those jacks with a typical Ethernet cable. A computer can be plugged into another jack and used to run the RCI software or telnet/ssh to manage the controllers.
    • Some routers have only Ethernet jack. That jack can be connected to an Ethernet switch or hub's WAN connector. Then the controllers and/or computer can be connected to the switch/hub's other connectors to get the same effect as if the router had more connectors.
    • It is not necessary that the router have any connection to the Internet just to make the controllers communicate with each other (although it won't hurt). The reason for using a router is that they typically have DHCP servers which allow the connected controllers and computers to automatically get compatible addresses.
  • Controllers can also be connected without using a router by using only an Ethernet switch or hub. The connections are done the same way as described above, but because there is no router to automatically set up the addresses, the controllers have to be assigned "static" addresses on the same subnet manually (typically using RCI on a computer connected to the controllers through a serial port). See the gateway manual for more information about setting the addresses manually. Note that if a computer is also connected to the switch/hub that its IP address, netmask and gateway will also have to be set manually.
    • Typical settings would be:
      • IP Address: (change the last number to 3, 4, 5, etc. for each additional controller/computer).
      • Netmask:
      • Gateway:
  • If the only things being connected via the network are two gateways controllers (no computer, no connection to the Internet, etc), they can be connected using only an Ethernet crossover cable (no switch/hub/router needed). Note that an Ethernet crossover cable is different than a normal Ethernet cable and much common. In most cases it is easier to find an inexpensive router/switch/hub than a crossover cable.

Point-to-point linking

Using RCI running on a Windows(tm) PC, connect to each of the gateways and configure one of the available virtual radio ports (6..12) for type "VoIP (RTP)". To do that:

  • Open the "Advanced Radio Properties" form by clicking on the gear icon for that port (grid view) or right-clicking on the port name.
  • Select the "Radio Type" tab.
  • Set the "Controllable type" setting to "VoIP (RTP)".
    • There is no need for the "Data enabled" option except when using MSAT-G2s.
  • Note the "RTP Port" number shown there. VoIP sent to this virtual port will need to be sent to that port number. It defaults to 21000+(2*port_number), which is 21012 for port 6, 21014 for port 7, etc.
  • It is also possible to adjust the audio quality/bandwidth and packet interval from this screen. Note that this setting affects VoIP sent by the unit so configured; it will automatically adjust to receive VoIP packets in any compatible format.
  • Close that form, or drag it out of the way.

Set up a route for that port that points to the other end of the point-to-point link. To do that:

  • On the main RCI form, make sure the grid interface is selected: find the "C" (classic) and "G" (grid) dots in the top right corner and make sure that "G" is selected (yellow).
  • For the virtual port (6..12) that you configured in the previous step, find the gear icon near the right edge of the screen and click on the rectangular box to its left; that will open the route selection form.
  • Right click in an open space in the route selection form to open the route editor.
  • Select an unused route. It is often convenient to use the virtual port number (6..12) for this, although any value from 000 to 999 is OK.
  • Set the route type to "RTP".
  • Set the description to the name of the other end of the link.
  • Set the destination address to the IP address of the other gateway that you want it to communicate with, and set the network "port" number to match the radio port's setting on the other unit (noted earlier, typically 21012 for radio port 6, 21014 for radio port 7...); this is similar in concept to setting the transmit frequency to the frequency of the other unit's receiver).

Once this is done on both controllers, the virtual ports should send audio back and forth exactly as if they were connected through a pair of link radios. Using RCI, those virtual ports should be put into "groups" with one or more of the physical radio ports so when audio is received on a repeater on port 1, for example, the same audio will be transmitted out of the virtual port to the other controller.

Multicast linking

When linking controllers using traditional radios, a single transmitter is sometimes used to communicate with more than one receiver (sometimes called a hub/spoke linking system). The same thing can be done using a network using "multicast". When using multicast, the controller sending the network packets does not send them to a specific receiver's IP address. Instead it sends them to a special range of multicast addresses (they start with 224 through 239). Then any (one or more) controller(s) on the same network on the same network can be set up to listen on that multicast IP address and they will all receive the transmitted audio data.

To configure this on the gateway, make sure all of the controllers involved are running V5.20 or later firmware, set them up as described in the Point-to-point linking section above, then set up routes for the virtual ports on each controller that use the IP address and port number 50000 (an arbitrary choice, but we use it consistently). If you want to have more than one such multicast connection using different virtual ports on each controller, for those ports use another multicast IP address,,, etc.

Linking over the Internet

All of the instructions above assume that the controllers involved are on the same network (more specifically, on the same subnet or for multicast, the same multicast domain). When controllers are on the same network like that, they can communicate directly with each other. When controllers are at different locations and/or are connected to different routers, they are often unable to communicate directly in that way (because the NAT firewall in the routers hides them). There are three general ways to deal with this and allow such controllers to communicate over the network, as described below.

Use public addresses

When a controller is connected to the Internet through a router, it is nearly always give an "private" or non-routable address beginning with 10.x.x.x or 192.168.x.x. This is done by the DHCP server in the router as part of its NAT (Network Address Translation) and is the method routers use to allow multiple connected devices to access the Internet through the single address assigned by the ISP (Internet Service Provider) to the router. This address translation hides the controller from anything trying to access it through the Internet, making it difficult to set up a link between controllers at different sites on such non-routable addresses.

It is sometimes possible to work around this problem by making the controller accessible on a "routable" IP address. Note that this works only for point-to-point links, not multicast (because the routers used by ISPs are generally not configured to pass multicast). Some of the ways to do this are:

  • Connect the controller to a "DMZ" (de-militarized zone) port on the router. A DMZ is a special Ethernet connector or setting you can apply to a normal Ethernet connector on a router that allows packets sent to the router's outside (routable) address to be forwarded to the gateway connected on the DMZ. In this case, it can allow the VoIP from another controller to be sent to the router's address and be received by the controller.
    • To find the router's outside address, from any computer connected to that router go to The IP address displayed there is the one that the controller at the other end of the link needs to send to. Note that unless you have arranged with your ISP to have a "static" IP address, that this routable address may change without notice (usually when the router reboots), which means that the connection between controllers will quit working until the address is fixed on the other end. Getting the ISP to assign your router a static IP address solves this problem. "Dynamic DNS" might be another solution in some cases, but is beyond the scope of this document.
    • Note that generally only one device per router can be connected to the DMZ. So this method can be helpful for connecting one controller in location A to one controller in location B, but won't handle multiple controllers at each site
  • As mentioned in the point above, it is possible (sometimes for a fee) to get an ISP to assign your router a static IP address so it won't change. It may also be possible to get an assignment for more than one static IP address. Setting up your network to handle this can be complicated, but it allows for multiple devices (such as controllers) to each have their own routable IP addresses. For example, you might have:
    • A DSL or cable modem/router connected to the ISP. To support multiple static IP addresses, the NAT feature in this device will probably need to be disabled. It may be easiest to set it to some kind of "transparent" mode.
    • If the above device doesn't have multiple Ethernet jacks, you may need to connect an Ethernet hub or switch to it.
    • Each controller that needs a routable IP address should be connected, then configured for a different one of the static IP addresses assigned by the ISP (along with the specified netmask and gateway settings).
    • If you have computers that also need Internet access, they could be set up on static IP addresses just like the controllers and connected like they are. Unless they are being used as web site servers and you are comfortable with the idea that hackers will be able to see them and try to break into them, you probably shouldn't do this. Instead, get another router (it doesn't need to support DSL or cable, but it does need a WAN connector). Connect its WAN connector to the router/hub/switch that the controllers are connected to, then plug your computer(s) into its LAN connector(s). That will hide your computers behind the NAT in the router, greatly reducing the chance of them being hacked into.
  • Yet another way to make a controller behind a router work with VoIP links over the Internet is to configure the router for "port forwarding". For example, you could tell the router that UDP packets received on port 21014 should be forwarded to port 21014 on the IP address, which might be the gateway. Then the controller at the other end could be set up to send VoIP to port 21014 at the router's outside routable IP address (get it with as described above) and the router would forward that VoIP to the controller. This method can be used for VoIP, but does not generally work for managing the controllers from another location (the two options above do) because telnet and SSH (which are used for managing) aren't generally supported by port forwarding.

Use a VPN

If a VPN tunnel is set up between the routers at each location they can make it appear that the devices at each end are all on the same network. This allows the controllers to communicate with each other just as if they were plugged into the same router. Depending on the VPN tunnel type, it may or may not support multicast, and it may affect the audio quality (by sending UDP packets through TCP links, etc).

Some routers have VPN host/client features built in. In other cases, you might need an additional router to handle the job; the DCB UT-3302 ( might be a good option (not tested but came recommended).

Use a "virtual trunk"

See Using VTrunk and Using VTrunk with Gateways.


Some of the tools that might be helpful for troubleshooting are:

  • Connect a computer to each gateway via a serial port. Then:
    • RCI can be used to find/set the IP address: <gateway name> Settings menu > Network Settings.
    • RCI can be used to set up virtual ports in RTP mode and set up routes to send VoIP to.
    • Serial terminal software (Hyperterminal, Putty, TeraTerm, etc, click here for more info) can be used to access the Linux command line of the gateway.
      • See "What are all the "{Start Remote Logging}{End Remote Logging}" messages?"
      • If you get a "IP2>" or "MSAT>" prompt, press CTRL-X to get to the "root:~>" prompt.
      • "ifconfig eth0" will display the IP address of the controller.
      • Try "ping" (or whatever the address of the other unit is) to see if it can be reached on the network. Press CTRL-C to stop that.
      • You can see info about the individual network packets being set back and forth by using "tcpdump". Before running it, save your settings on the controller (using RCI's File > Save Settings on <gateway name> option or run "client" then "207 1" ENTER then CTRL-X). You can stop tcpdump with CTRL-C, but then run "reboot" because it messes up some of the network interface stuff (reboot will cause you to lose any settings changes you haven't saved).
  • You can use a computer to view the network packets sent and received by the gateway if you connect them both to a network hub (a switch won't work, and hubs are getting hard to find) and you run WireShark on the computer. This is pretty low-level stuff, with a steep learning curve.

Personal tools