One of the problems with interfacing VoIP systems with radio equipment is that both are 'simplex' in operation. Both the VoIP and radio circuits occupy a single channel, therefore they can only be in either transmit or receive but never both. The Gateway must switch the direction of audio flow through it if two-way communication is to be successful. If one side of the Gateway is permanently busy with traffic, the Gateway can become locked in a single direction. In practice, the VoIP side of the Gateway is not a problem: when a station finishes their transmission, the channel falls silent and the Gateway is free to switch. It is not quite so clear cut on the radio side. Even with the use of both noise-based and speech recognition squelch, the receiver can still be excited by unwanted audio. An example of this is when strong radio stations are operating close to the Gateway frequency, within the receiver passband.
To get round this problem, a method of remotely forcing the Gateway's HF radio into transmit is required. Fortunately, the radio amateur world enjoys the skills of Len Stefanelli, N8AD, who has devised many ingenious software solutions for controlling radio transceivers. He was both patient and kind in assisting me and he has developed a small and robust program for allowing a remote VoIP user to directly control the radio transmit/receive (PTT) line.
The way it works is that the Gateway runs a simple TCP server program. The remote VoIP user runs the corresponding TCP client program. The remote user firstly issues a connect command and, via the Internet, the Gateway operator receives an incoming connect request. The Gateway operator can allow or deny access depending on the credentials provided - if there is any confusion the two can use a simple text box to exchange questions and answers. Once the remote user has been granted access, they see a small control screen containing a large red button and a large green button. These two buttons are the transmit and receive buttons respectively. When the user clicks on the red button, the remote TCP command forces the Gateway radio into transmit. They can then speak over the VoIP circuit knowing that threy are being relayed onto the radio channel. When they have finished speaking, they click on the green button and the radio drops back into receive.
This system is simple, yet secure, and always remains entirely under the supervisory control of the Gateway operator. Multiple clients can all log in at the same time so that, if a net forms on the VoIP side, any participant can control the PTT switching (although good practice would suggest that the Gateway operator only allows the current VoIP Net Control Station access to the PTT switch).
To function with this system in practice, the Gateway operator removes all squelch controls from the radio receiver. The receiver produces permanent audio, whether noise or wanted speech. The Gateway is locked in one direction, from radio channel to VoIP channel. VoIP users are now effectively monitoring the radio channel all of the time. If a call is received on the radio channel, the VoIP Control Station can force the transceiver into transmit in order to reply. This way of working is very solid and positive in action.
There are a couple of caveats. The first is that the client software may require the download of a suitable .OCX file that is not standard to some Windows set-ups - some users may be reluctant to download this extra but they need have no concern and its installation is a matter of moments. Secondly, it has to be carefully understood that the TCP circuit that is instructing the radio PTT is virtually instantaneous even when the connection is right across the world. However, the VoIP speech channel takes longer to encode, transport and decode, and the delays can increase to several seconds if additional proxy servers are being used. Therefore, the person controlling the PTT must remember not to hit the 'receive' green button the moment they have stopped talking because to do so would have the effect of chopping off the last few seconds of their speech as transmitted on the radio channel! Testing has so far shown that the remote user should count to about five seconds before hitting the green button. By the same consideration, the radio users need to understand that they should wait for five seconds before expecting a reply via the Gateway in this mode.