Interconnecting EchoLink and IRLP and EchoIRLP
This page has received hits since November 16 2002
Interconnection of different Internet linking systems has been a vexing question in recent times. Each system has its standards of operation and cultural base. Interconnections run a real risk of violating these unique qualities of each system, ruining the Internet linking for everyone - users and operators alike. Due to a sudden and unexpected increase in the number of uncontrolled links between the systems in late 2002, I had been forced to release information to the public earlier than anticipated. My view is I'd rather see cross linking managed than let it develop in an ad-hoc fashion. This page outlines the design goals of IRLP-EchoLink interconnections and then details current work underway to implement these recommendations. The end result is the EchoIRLP project, which developed during 2003.
IRLP - EchoLink - the problem:The issues involved in interconnecting IRLP and EchoLink involve the differences between the two systems. While on the surface, IRLP and EchoLink look somewhat similar, they are actually quite different in their approaches. The important differences include:
Looking at the differences, we can see that in the first case, the two networks have opposing views on the desirability of PC connections to nodes. Node owners have gravitated to one network or the other on this point alone, in many cases. Interconnecting the two networks will cause some IRLP node owners to feel violated, because there's a loophole that allows the PC users to connect to their node - the very thing they chose to avoid by using IRLP.
On the second point, it is worth mentioning that security is only as good as its weakest link. Allowing the IRLP and EchoLink networks to become interconnected without additional node owner controls reduces IRLP's effective security level to little more than what EchoLink offers.
Guidelines for IRLP - EchoLink Interconnection.
Now we're a bit more familiar with the issues involved (and ignoring the extreme isolationists on both sides :) ), we can formulate some guidelines for the interconnection of the two networks. I have identified two interconnection scenarios that minimise the impact of interconnections between the EchoLink and IRLP networks. One of those scenarios has two sub types. The possible schemes for interconnecting the systems are as follows:
These interconnection scenarios will be described in detail below.
Common conference server - The basic idea is of a conference server capable of accepting connections from either IRLP or EchoLink nodes. Nodes wishing to communicate across the IRLP - EchoLink boundary can connected to one of the common servers using their native protocol and communicate as though connected to a native network. Because the conferences require a deliberate action to connect to, and also their node addresses are known on both sides, it is easy for people on either side of the server to lock it out if they don't wish to be able to connect to the other network. The technology to perform this sort of interconnection already exists and has been extensively tested, as well as custom IRLP scripts to transparently connect to IRLP capable EchoLink conferences. This is a 100% opt in system, as it is not possible for an IRLP node to find the shared conference servers without the addition of extra scripts. Because both networks are capable of GSM audio compression (standard for EchoLink and an option for IRLP), and the transport protocols are quite similar, the conference server is able to perform a relatively simple protocol translation and relay the audio between IRLP and EchoLink without any degradation of quality - something existing interconnections cannot claim, as they decode right back to analogue audio and then recode.
Linked IRLP and EchoLink conference servers - This is
to the above scenario, except that the IRLP and EchoLink conferences
separate servers. The main advantages of this sort of system are
native security protocols can be more easily used on both servers, and
traffic capacity can be increased (by having the IRLP and EchoLink
separate sites). Up until mid 2004, such linked servers were
implemented using an analogue technique, using two nodes (1 IRLP, 1
EchoLink) back to back. During August and September 2004,
software was developed to enable a digital link between an IRLP
reflector (GSM subchannels only) and an EchoLink conference. The
first test link was installed in August 2004, with the first
"production" links comong online in October 2004. Look forward to
more officially sanctioned cross system nets in 2005! The first
net to use the digital interlink officially will be the VoIP Skywarn
net in late 2004. I am also looking at the feasibility of moving
the cross system gateway to within an IRLP reflector. This will
require some assistance from Dave Cameron VE7LTD to test and
implement. The single server solution has the advantages of
simplicity and security, at the cost of capacity, as all nodes will be
using the same system's bandwidth.
Dual system node - This offers a different approach to the shared server approaches. In effect, the IRLP - EchoLink function is moved _within_ the IRLP node itself. There are two ways of achieving this. The first is to simply run an IRLP and EchoLink system side by side, but provide some form of signalling between the two systems so that only one can be active. The downside of this is it requires some extra hardware (at the very least, another interface board and soundcard, if a Linux EchoLink program is used on the IRLP machine), and if run on two separate machines, there may be race conditions in the signalling. An alternative approach is to actually run an IRLP node with an EchoLink gateway on the same box itself. The IRLP software will control all operations and call on the EchoLink gateway components when they are required. For incoming EchoLink calls, the EchoLink gateway will signal the IRLP software by means of a scripted interface. This allows one box to fulfil both roles and ensures that while users can decide which system to connect to, and that the node is a fully functioning node in both networks, it can't create a link between the networks. The current version of EchoIRLP supports this mode of operation and has been extensively used in the field as of late 2004.
A variation of this approach, which uses a modified EchoLinux client to connect to the EchoLink nodes, under control of the IRLP system is currently under development in the USA and is likely to be released in early 2003. The net result will be the same - a node capable of connecting to either EchoLink or IRLP, but not link the two networks together. As of 2004, development of the echoLinux approach seems to have stalled.
The reason for choosing IRLP as the base platform for a dual system node is because of the authentication requirements of IRLP, which require an IRLP node, as well as the extreme flexibility of the IRLP platform.
Future plans involve tightening the integration between EchoIRLP and the IRLP network. This will enable the EchoIRLP scripts to seamlessly intergrate into the IRLP node, creating a unified user interface for the end user (as of Feb 2004, the system is already very transparent). Liaison with the IRLP developers is underway to define and have provided the necessary hooks to smooth off the remaining rough edges.
The final scenario deserves a mention. Emergency communications is almost always a universal exception to the normal network rules, so the normal principle of keeping the networks separate no longer applies. However, cross links used for emergencies, training and special events should adhere to the following guidelines:
EchoIRLP - Design and Architecture.
The EchoIRLP system is capable of implementing both the shared conference and dual system modes of operation. Selection of the mode of operation is done by a number of environment variables. In addition, EchoIRLP is capable of operating in shared conference mode when connecting to known shared conferences, while using native EchoLink protocols for all other EchoLink connections, if required.
The design goals for EchoIRLP were (and still are) as follows:
In shared conference mode, EchoIRLP can only connect to conferences defined in a echo_conf file. The echo_conf file contains the conference name, IP address, node number and connection password for each conference. An additional option allows the node owner to choose whether to use the EchoLink directory servers or the static entries in the hosts file to resolve the IP address for the conference. Using the hosts file allows the IRLP node to connect to the conference without any association to the EchoLink network. The disadvantage is that if the IP address changes, the connection will fail. Using the directory servers resolves this problem, but requires an EchoLink ID to be registered for the node, so it can log in.
Once the IP address of the conference is known, the IRLP node makes a connection using the IRLP binaries to the gateway ports on the conference server. In addition, it sets the IRLP busy status to show it's connected to itself, which is the accepted way of showing that the node is connected to something other than IRLP. Additional status files contain the connection information for the actual shared conference connection.
Full dual system operation requires a copy of thebridge to be configured as a dedicated gateway for the node. Normally thebridge is run on the IRLP node itself (localhost) for ease of intercommunication, though there are hooks to allow for thebridge to be run on a separate machine. The extra software looks after all the EchoLink functions - logging in, resolving IP addresses, connecting to nodes and receiving incoming calls. The interface between the EchoIRLP scripts and thebridge is via a two-way scripting interface:
Connecting to an EchoLink node using thebridge is similar to the shared conference method with the following exceptions:
Finally, to meet the guidelines at the top of this page, there needs to be some mechanism to prevent the systems becoming cross linked accidentally. This is achieved on two levels. Firstly, the architecture makes it extremely difficult to cross link the two networks. EchoIRLP uses the same hardware and software that IRLP itself requires, and it is extremely difficult to share this in a way that would allow a cross link to work. Secondly, the software itself has multiple checks for pre-existing connections. Because EchoIRLP sets the IRLP active file, any attempt to connect from IRLP while an EchoLink connection is in progress results in a busy response being sent to the remote IRLP node. Similarly for inbound connections, the EchoIRLP code checks all combinations of IRLP and EchoLink active files to determine the state of the system, and only allows the connection to proceed if there is no possibility of a cross link (i.e. the node is idle or already in an EchoLink connection). Also, EchoIRLP uses the same methods as IRLP itself to check if the channel is busy and can report this status back to the calling node. For outbound connections, once the node is connected to another system, no further outbound connections can be made. This may change in future versions of EchoIRLP.
Additional checks are also performed to see if the calling node is permitted to connect to the system. This is controlled by 3 access control lists on the system, which are fully node owner configurable.
As of 2004, EchoIRLP is moving to automated updates, like IRLP itself. This will make the system painless for node owners to maintain, as the bulk of the work will be done automatically, just as with IRLP itself.
eQSO - EchoLink/IRLP Gateway - Concept Discussion
While discussing inter-system gateways, it is worth considering what might be required to allow eQSO to be coupled into shared conferences between eQSO and other networks. While eQSO cross links already exist with EchoLink, these are implemented by coupling an EchoLink node to an eQSO node, which introduces some timing issues with PTT signalling, as well as degradation of audio quality because of the extra passes decoding and re-coding.
A better approach would be to have a piece of software perform the translation between the different transport protocols. From my understanding, eQSO also uses the GSM 6.10 codec, same as EchoLink and one of the options with IRLP. However, eQSO uses a TCP transport instead of the UDP based transports that EchoLink and IRLP utilise. Because the codecs are all compatible between the three systems, it appears that a relatively simple transport protocol conversion could be managed between eQSO, EchoLink and IRLP. Also, because eQSO is server based (no peer-peer links), only the shared conference scenario needs to be considered. The more complex peer-peer gateways are not required for eQSO, but integrating an eQSO client onto an IRLP node EchoIRLP style could be an interesting exercise.
Having eQSO capabilities on a shared conference server also has some interesting engineering implications. eQSO uses a simple outbound TCP connection for its audio path. This type of connection easily negotiates NAT gateways, unlike the UDP implementations. This could be exploited to allow "split site" IRLP or EchoLink systems, where the native IRLP or EchoLink part of the system lives on a convenient public IP address, and the radio side is attached to a copy of eQSO running in the shack. Security could be enforced using Linux iptables to prevent other hosts connecting to the gateway. Multiple eQSO clients can live behind the same NAT router with a single public IP address.
For such a system to be feasible, the eQSO protocols
be opened up in the same way that the EchoLink protocols were opened up
uses the Speak Freely protocol for its audio transport, for which an
implementation has always been available). I have it on good
authority that the eQSO protocols will not be opened up in the
forseeable future, however, there is a good possibility of working with
the developers to bring eQSO into the cross system fold at the digital
level, with an open interface to the eQSO system being a real
I have presented the scenario of IRLP - EchoLink cross linking and some of the issues surrounding such links. The issues were considered in detail, and a range of possible solutions were presented. The solutions presented involved either providing a common conference service where nodes of both systems could connect and communicate with each other, or nodes capable of communicating natively as a full member node of each system, but unable to create a link between the systems. It is anticipated that both connection types would be utilised in practice, as they serve very different needs.
Software development to achieve the above aims has already commenced and a number of experimental conference bridges have already been extensively tested by both IRLP and EchoLink nodes. IRLP scripts to connect to these servers has also been written and tested. A dual IRLP/EchoLink node is under development and is expected to be released in early 2003. Update: I have a partial implementation of a dual system node working. It is awaiting some more development of the gateway code, before I can continue developing the scripts.
The question of interconnecting IRLP and EchoLink is not if, but when and how. The how should be managed, to obtain a better result for all. Similarly, interconnections to eQSO and other networks will also happen, though at a slower rate, because of the greater protocol differences, and the fact that the eQSO protocol is not yet in the public domain.
|The official EchoIRLP page||http://www.echoirlp.com|
|Internet Radio Linking Project||http://www.irlp.net/|
|CQiNet home of the Bridge and EchoLinux||http://cqinet.sourceforge.net/|
|IRLP forum at Yahoo Groups||http://groups.yahoo.com/group/irlp/|
|EchoLink forum at Yahoo Groups||http://groups.yahoo.com/group/echolink/|
|EchoLink Status Page||http://wa2dci.com/echo_status.php|
|IRLP Status Page (with EchoIRLP status)||http://wa2dci.com/status.php|
|Speak Freely - UNIX||http://www.fourmilab.ch/speakfree/unix/|
|Speak Freely - Windows||http://www.fourmilab.ch/speakfree/windows|
|Yeasu WIRES II||http://www.vxstd.com/en/wiresinfo-en/|