Satellite VoIP using a hardware solution
by John Watson
There are several ways to use VoIP technology. For this application the requirements are that the telephone look and operate like any ordinary telephone set. It should ring when called, even in the middle of the night, or place calls in the usual way with no training. Having an extra extension on the night stand would be a big plus. The other end of the connection is the company that provides the dial tone. There are companies that provide dial tone via the internet, like Vonage, SIPphone or Crystal Voice, or you can choose to be your own provider. All that is needed is a good full time connection, with routable IP, on the internet from home or office and a phone line to answer. My choice is to use the office PBX to provide the dial tone, connect that to a VoIP modem, and connect that to the internet with it's own public routable IP address. That address could be a dynamic IP, using a service like DynDNS.com. The big advantage for me is that any company employee can call me with just a local extension. Even the phones in the production area that donít have access to outside lines can call. The maximum bandwidth requirement is only 20k bps. At the mobile end I have telephone sets, plugged into a VoIP modem and connected to the EtherSat Satellite Internet system, using an iDirect modem. The service must provide at least one routable (static) IP address and sufficient uplink bandwidth. I am on the 128k/1m service plan, with a MotoSat XF3 mount. I have tested this on the lowest account using the F1 conversion dish on iDirect service. There is a workaround (VPN), if a static IP at the remote location is not an option.
When a call comes in, the telephone office (or business PBX unit) puts a ringing signal on a pair of wires connected to the FXO modem. That term comes from phone company language that means that it looks like a telephone set. The modem answers the phone and then tries to find its mate, over the internet. That's why we need a static IP, or VPN. After finding the mate to the modem, control messages are sent to request the FXS modem at the remote end to send a ringing signal to the telephone set. Again, in telephone speak, the FXS means that it looks like the switch, it provides the dial tone and ringing signal. From here on, analog voice and tones are converted to digital messages and then back again to make it act like simply two telephones and a wire. When I pick up the phone in the motorhome, the reverse happens. My modem tries to find its mate by using an IP address programmed into it via the configuration screen or by name to be resolved by a dynamic name service that will point to the FXO modem.
To clarify the minimum networking requirements: With the Mult-Ttech modems in SPP mode, that is a proprietary mode that has minimal network requirements, they only need to pass data using UDP protocol over a single port. That port is 10,000 by default, but can be changed to anything that does not conflict. That makes it very hard for a service provider to block your VoIP traffic. For a minimal configuration, all that is needed is a router to forward the UDP packets for the port you select from the public internet to the VoIP modems, both FXS and FXO. I am using the Multi-Tech MVP130 and MVP130-FXS single channel VoIP modems. I recommend a router that can apply bandwidth management to prioritize the VoIP data. This could be done by the iDirect modem. If you're using iDirect service, then your service provider can apply QOS (quality of service) parameters to your connection to prioritize your voice traffic over your connection. Some Internet providers will, for a fee of about $20 a month, provide 20 kbs of CIR (committed information rate) to greatly improve the probability that your voice packets will travel through the network on a timely basis.
There are performance issues to be considered. When voice goes into the phone, the modem encodes this analog voice data into digital data using a codec program, I use NetCoder 6.4. I find G.729 to be equally acceptable. The VoIP modem from Multi-Tech allows 15 choices of codecs. If your modem of choice uses only the G.711 coder, as do many of the inexpensive modems typically used on SIP phones, then the 80 kbs required will demand a better satellite Internet connection. I have tested one of these phones from Mitel and found the voice quality to be superb, however the bandwidth requirements were significant. There is also the possibility of adding forward error correction data. I find that FEC reduces the occurrences of short breaks in the voice. On slower connections, this extra bandwidth may not be available and FEC becomes a performance penalty. The remote end hears perfectly, due to the larger downlink bandwidth. The other end, the regular telephone user, may suffer dropouts in reception. This is due to lost packets. If a packet is received in error and re-transmitted, the re-transmitted packet is received too late to be of any use. Consequently, setting the packet retry maximum higher than one is a waste of bandwidth. A good measure is the ping test. If ping times exceed 1300ms more than once in 10 pings, or the variation in ping time exceeds 400ms, then VoIP will probably be unacceptable on this connection.
The variation in round trip delay or latency seems to be worse on the remote uplink path. The modems have a jitter buffer to delay the voice and allow the packets to be re-assembled. I choose to set the minimum jitter buffer size to 300ms while leaving the maximum at 400ms. For no apparent reason, setting the uplink packet size to 100ms seems to work best for me. This is a function of the service provider. The Multi-Tech tech support department recommends the shortest possible packet size, 20ms for satellite connections. Some testing would quickly show your optimum value.
One variation that I have tested, with minimal performance impact, is the use of VoIP over VPN. By using an IPsec compatible router to establish a two-way security association with authentication and encryption like SHA1 & AES-256, it is possible to secure the conversation to a level that would be acceptable to most commercial and some government applications.
A VPN connection can also be used to allow the remote location to connect using Network Address Translation Traversal (NAT-T), aggressive mode and keep-alive. This procedure places a TCP wrapper around the UDP data, and there is a slight performance penalty. Conventional wisdom would suggest that this performance penalty would be severe, but as measured here, that is simply not the case. This option removes the requirement for a static IP at the remote location. I am using it here, where I have 2 VoIP phones using two different VPN connections.
In another variation, the modems can be programmed to work in groups, so that when dialed, they would return a secondary dial tone and accept one or more digits that would select which remote location to be connected. One fixed location could support several remote satellite users, but only one at a time.
In another possible application, with a command center vehicle and an office equipped with SIP phones, (G.729) it would be possible, before deploying the command center, to gather phones from designated offices and plug those into the command center network making it ready for key people to assume their responsibilities when deployed.
About the author: John is a programmer/consultant who fulltimes in his motorhome. He frequently boondocks out of cell-phone range, and needs VoIP to keep his business up and running. At the time of this writing he is providing technical support and custom data analysis programming for the Ethersat iDirect network.