This page deals with the issue of interoperability between the various Amateur Radio VoIP systems, and attempts to keep up to date with progress in this field. Interoperability has been an ongoing issue in the VoIP world since 2002.
Why interoperate between different systems?
There are many reasons why it is desirable to operate across the different VoIP systems. The most obvious is during emergency communications scenarios, where users who need to communicate to pass emergency traffic have access only to different systems. For example, User 1 can only reach the local IRLP node, and needs to pass traffic to User 2, who only has EchoLink running on their PC. Without technical solutions, the only way traffic could pass between User 1 and User 2 is with the aid of a manual relay who has access to both systems.
Another common scenario is a local repeater owner who wants to offer access to multiple systems, one at a time, using the one repeater and a single computer/hardware interface. A VoIP solution that can connect to the different VoIP networks can save a lot of money, rack space and electricity. It is also likely to be easier to manage.
Why not interoperate?
There are valid reasons not to link multiple systems together. Each VoIP system has its own culture, standards of operation, rules and other characteristics that make it unique. Some systems only allow access via radio, and others allow access from PCs. Some are even PC only (e.g. CQ100 - although people have worked how to build RF gateways here). Uncontrolled bridging between different systems causes many problems, both technical and social. There are situations where linking systems together works well, and should be encouraged, and there are situations where bridging systems should be avoided.
There is room in the middle ground for multi-system nodes to provide flexibility for users to connect to nodes in different networks, as well as some limited applications for bridging foreign networks in a controlled manner.
Interoperability Scenarios
There are two basic scenarios that will be considered here. The first is the multi-system node. These are configurations which allow allow a user to access nodes on one of the systems the node is capable of connecting to. The second scenario is gateways that link two or more different VoIP systems together. These will be referred to as gateways.
Gateway Types
There are several different types of gateway that can be used to link two different systems together. The different gateway types have different strengths and weaknesses, and are described below:
Analogue Gateway
This is the simplest type of gateway. An analogue gateway is simply two or more nodes, one for each system being linked, being connected back to back, with audio and control inputs being routed to audio and control inputs of the others.
Pros
The main advantages of analogue gateways are that they are easy in concept, and easy for many amateurs to implement. Analogue gateways are also able to be built to link almost any two networks together, because they decode back to audio and simple DC control signals.
Cons
The biggest disadvantage of analogue gateways is they have the lowest audio quality and highest latency of any of the gateway types. Analogue gateways also require the most hardware. Analogue gateways should be avoided where possible, and only be used as a last resort.
Transcoding Gateway
Transcoding gateways convert the signal formats from one system to another by decoding audio from one network back to straight PCM, then re-encoding it into the format for the other system. A transcoding gateway may consist of a single piece of software performing the entire transcoding operation (e.g. Asterisk, thelinkbox), or it may be two (or more) pieces of software working together (e.g. anything interfacing to Skype uses Skype to process its own audio via the Skype API), and passing raw digital audio between the components. Sometimes, hardware may be required, such as when handling the AMBE coded audio from D-STAR systems.
Pros
The main advantages of the transcoding gateway is that it can be made compatible with a wide range of networks, and it offers a good balance between audio quality and inter-system compatibility.
Cons
Transcoding gateways are flexible, but they are unable to deal with systems which have closed specifications, because no one is able to write a transcoder for closed systems. Transcoding gateways usually slightly degrade the audio passing through them, due to the use of lossy codecs. However, this distortion is usually not easily noticed.
Packet Translating Gateway
Packet translating gateways are in some ways the simplest gateway. Packet repeating gateways simply take packets from one VoIP system, strip off the headers, leaving the audio intact, then re-package the data for the other network(s).
Pros
Packet translating gateways use very little CPU power, so they can be run on low end hardware and also incorporate conferences for a very large number of users. Because they don't touch the compressed audio data, packet translating gateways do not degrade the audio passing through them.
Cons
Because packet translating gateways don't process the audio stream, they can only be used when the the VoIP systems they link use the same audio codec.
This section looks at each of the VoIP systems in use, and details what interoperability solutions exist, and what pitfalls are there for the unwary. Each system will be covered, with a list of known multi-system node and gateway solutions, as well as comments.
IRLP
IRLP is one of the most versatile starting points for interoperability scenarios. While the actual IRLP binaries are closed source, IRLP uses the open Speak Freely protocol for its audio. Because of this open audio protocol, as well as IRLP being internally based around a number of shell scripts, a number of interoperability solutions exist:
Multi-system node
EchoIRLP is a set of add-on scripts and software for IRLP which adds EchoLink capability to an IRLP node. EchoIRLP requires no extra hardware, and enforces separation between the IRLP and EchoLink networks, so an EchoIRLP node can't be used as a gateway.
app_rpt, the radio interface for Asterisk can be used to create a node capable of IRLP, EchoLink and AllStar connectivity. However, there are issues with separation between the networks, which can cause conflict with IRLP policies.
rtpDir can also be used to build an EchoIRLP like node, with similar capabilities. rtpDir can also add AllStar (with Asterisk) and D-STAR (DPlus/dExtra only) capabilities.
Gateway - Several gateway solutions exist, depending on the requirements. Some of the known gateways for IRLP include:
Integrated conference. This is an enhancement to IRLP reflector that adds EchoLink capabilities directly into IRLP reflectors. Version 1 of the integrated conference supports only a single integrated channel, using a packet translator. Version 2 of the integrated conference is even more tightly integrated into the IRLP reflector architecture. Version 2 of the integrated conference supports both packet translation and transcoding reflector channels. It also allows up to all 10 available reflector channels to be configured as IRLP-EchoLink gateways.
thebridge, written by WB6YMH, can be used both as the core of an integrated conference, and can also be used as a packet translator between its own EchoLink conference and a remote IRLP reflector.
thelinkbox, again by WB6YMH can additionally be used as a transcoder between and EchoLink conference and an IRLP reflector channel.
rtpDir can be used as a transcoding gateway between IRLP, EchoLink, AllStar (with the addition of Asterisk/app_rpt) and D-STAR (DPlus and dExtra only).
app_rpt can be used as a transcoding gateway between IRLP, EchoLink and AllStar networks.
Notes
IRLP is very strict on network access policies. Gateways must not allow foreign nodes to be able to connect to arbitrary IRLP nodes, and IRLP nodes must not contain a gateway - gateways must be linked to (or be a part of) reflectors only. Multi system nodes must ensure that they don't inadvertently become gateways by linking foreign nodes to an IRLP connection is progress. EchoIRLP has lockouts to prevent this happening. Other multi-system nodes may or may not have the appropriate lockouts. BE WARNED, failure to abide by these policies has led to nodes being blocked from the network! However, well behaved gateways have been running on IRLP reflectors since at least 2004, with the blessing of the IRLP administration, and David Cameron, VE7LTD has been a major help with the development of the integrated conference system.
EchoLink
Like IRLP, EchoLink, being an open protocol with several open source implementations, has a multitude of interoperability solutions. Much of what has been written for IRLP is also valid for EchoLink.
Multi System Node
The multi-system node solutions for IRLP also include EchoLink, so we have:
EchoIRLP - Allows IRLP and EchoLink access from a single node. Includes all necessary lockouts.
app_rpt - Allows access to EchoLink, IRLP and AllStar
rtpDir - Allows access to EchoLink, IRLP, AllStar and D-STAR (DPlus/dExtra only).
Gateways. See IRLP Gateways section for list of gateways for EchoLink, as they are the same.
Notes
EchoLink access policies forbid connecting EchoLink stations to foreign networks that allow direct access from a PC. However, connecting to foreign networks that allow only RF access (e.g. IRLP) is fine.
eQSO
eQSO is a closed source, Windows only linking system. Unlike IRLP or EchoLink, eQSO requires no router or firewall configuration to get going in most cases. However, because its protocols are proprietary, the only way to link eQSO to other VoIP networks is via an analogue gateway. eQSO has no API, to assist with the construction of gateways ot multi-system nodes.
WiRES II
WiRES II is a commercial application for amateurs, sold and distributed by Vertex Standard (Yaesu). Like eQSO, WiRES is available only for windows, uses proprietary protocols and has no programming API. An analogue gateway is the only way to link WiRES II to other VoIP networks. Without an API, multi-system nodes are tricky to manage.
app_rpt/Asterisk/AllStar
Asterisk is an open source telephony platform. app_rpt is an Asterisk application, which adds radio linking functionality and allow Asterisk to act as a repeater controller. AllStar is a network of Astrisk nodes running app_rpt, using a common addressing scheme. Because Asterisk and app_rpt are open source, and support open protocols, multi-system nodes and gateways can be built using this platform.
Multi System Node
Asterisk comes with chan_irlp and chan_echolink, for connection to IRLP and EchoLink networks respectively. However, caution needs to be taken to ensure that an Asterisk based noce complies with IRLP requirements, when connected to IRLP. Asterisk can also link to rtpDir using chan_rtpdir, which then allows D-STAR to be incorporated.
Gateways
Asterisk is a capable conference server, and can be readily linked to IRLP and EchoLink conferences. Asterisk also has inbuilt transcoding capabilities, and supports all of the codecs that are used in IRLP and EchoLink (in addition to many others used for telephony), so it can be used as a transcoding gateway. With the addition of rtpDir and a DV Dongle, an Asterisk conference could be linked to a D-STAR reflector as well.
CQ 100
CQ 100 is a commercial application which is described as a "virtual ionosphere", and is a PC based amateur radio simulator, which can also be used for PC-PC based communication between radio amateurs. While CQ 100 was originally not intended for connection to radios, there are said to be radio gateways available on the system. Other than analogue gateways, interoperability options with other VoIP systems are not known, and it is not known whether CQ 100 has an API to allow external programs to interact with it. More research is needed nere.
D-STAR
D-STAR is not a VoIP system in the same way as the others, but a digital voice and data system, which is capable of using the Internet as a transport medium to link distant D-STAR sites. This discussion will deal with the narrowband "DV" mode of D-STAR only, and concentrate mainly on the voice stream. D-STAR uses the proprietary AMBE codec to encode the voice into a 2.4 kbps bandwidth. However, the codec is readily available in hardware, so any systems that need to decode D-STAR voice will need to add hardware containing the AMBE chip to process the audio. Prepackaged devices exist for this purpose, such as the DV Dongle. The DV mode data stream is effectively a simple serial stream between the endpoints. No error checking is used, and the raw data is available on a port on all D-STAR radios, as well as some versions of the DVTool software that is used with the DV Dongle. The on air protocol of D-STAR is open specification, and the Internet protocols have been reverse engineered.
Multi System Node
A true D-STAR/analogue dual mode node has just come into existence. Software written by G4KLX allows the node to determine if a signal is D-STAR or analogue in nature, and route it accordingly. This could be combined with an existing VoIP system on the analogue side, to allow multiple VoIP systems plus D-STAR to be accessed on the same frequency. This system, combined with the desired Internet back ends is the makings of a very versatile multi-system node. A DV Dongle is not required here, since there is no need for the node to actually decode D-STAR audio (We are keeping the networks separate! :) ).
Gateways
As previously mentioned, rtpDir can be used as a transcoding gateway (with the addition of a DV Dongle to handle D-STAR audio) to link IRLP and EchoLink nodes to the DPlus and dExtra modes of operation. However, traditional D-STAR callsign routing is not easily supported. There have been proposals to link Asterisk to D-STAR, and use its PBX routing capabilities to interface with D-STAR's callsign routing. However, no system of this type actually exists.
On the data side, some gateways already exist. For example, D-PRS positioning data is routinely gated to the APRS network, so D-STAR users can report their position to the global APRS network. Other data gateways (e.g. D-STAR to EchoLink text) are not known to exist at this time.
Notes
Linking of traditional analogue and VoIP systems to D-STAR is a very contentious issue as of early 2010. Only one D-STAR reflector, REF015, is allowed to carry signals which originate from non D-STAR sources. Experimentation in this field has slowed considerably. Also, the D-STAR/DPlus infrastructure is still evolving in response to the demands of the amateur community, and suitable means of identifying the source of audio, and controlling access to different parts of the network are still in development. Multi-system nodes on D-STAR are looked upon favourably, in general, as they keep D-STAR separated from other systems.
Interoperability in Practice
There are a number of situations where interoperability between the different VoIP networks. Multi-system nodes allow repeater and link hardware to be economically time-shared between networks, and give local users more places to connect to. Many IRLP node owners, for instance, have installed EchoIRLP for EchoLink capabilities. Similarly, many AllStar node owners have added IRLP and/or EchoLink capabilities to their systems.
Gateways have been successfully used in a number of scenarios. One of the most well known is the VoIP WX Net, which uses an IRLP/EchoLink integrated conference to allow IRLP and EchoLink stations to freely interoperate on the net. Other emergency groups around the world now use similar IRLP/EchoLink integration. However, even ragchew nets have benefited from interoperability. Having a large IRLP/EchoLink integrated conference at the heart of the Australian/Irish network has enabled IRLP and EchoLink users around the world to talk to each other. From time to time, there have been gateways to other networks, as well. IRLP/Echolink integrated conferences are also used for club nets, news broadcasts, themed nets (e.g. AMSAT-VK monthly nets) and other events, where it is desirable to have a large number of participants.