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: 

• EchoLink allows users to use their PC to connect to the network.  IRLP is designed to prevent this sort of connection.
• IRLP uses a PGP based authentication scheme.  EchoLink uses a simpler password scheme, and its callsign validation procedures are not accepted as adequate by all parts of the IRLP community.

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:

1. Common conference server capable of accepting connections from IRLP or EchoLink nodes.
2. Permanently linked IRLP and EchoLink conference servers (an extension to #1).
3. Dual system capable IRLP node.
4. Temporary cross links for emergencies and special events.

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 similar to the above scenario, except that the IRLP and EchoLink conferences reside on separate servers.  The main advantages of this sort of system are that native security protocols can be more easily used on both servers, and also traffic capacity can be increased (by having the IRLP and EchoLink servers on 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:

• If possible, obtain prior permission from the node and conference owners involved (obviously, in an emergency, this is not always possible).
• Nodes connected to the crosslink should not have any tails, IDs or other extraneous signals propagating into the link.  These are a real problem on large nets.
• Facilities to allow "monitor only" connections should be provided.  This can be done using either EchoLink or conventional streaming audio (MP3/Ogg Vorbis/Real Media/Windows Media).
• The crosslink itself needs to be of as high a quality as possible and should avoid an RF link between the networks.  There is already enough loss of quality due to the codec change involved. Now that a digital interlink is feasible, I recommend that all cross links use the new digital system.  This provides the highest audio quality and lowest latency.  The digital system can link an EchoLink conference to a GSM IRLP reflector (ADPCM is not supported and there is almost no advantage in doing so, as performance won't be much better than existing hardwired analogue gateways).
  

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:

• The system must not cross link the two networks
• EchoIRLP must support local conferencing.  This is because PC connections consume one connection per person, which is inefficient.  Besides, Windows EchoLink users are used to this ability too.
• The system needs to be as transparent as possible to the end user.
• EchoIRLP must maintain the technical standards of IRLP itself with regards to channel management (i.e. it must respect busy channels, etc).
• EchoIRLP should report as much useful information back to the connecting user in the event of connection failure or other unexpected events.

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:  

• Commands are sent to thebridge using a utility called tbdcmd.  This gives the scripts complete control of the EchoLink side of the system.
• Events from thebridge are sent to a special script (in EchoIRLP, it's called echoirlp-status) which determines the event type and then passes control to the appropriate script for that event.  This allows the system to respond to incoming connections, disconnections and status changes.

Connecting to an EchoLink node using thebridge is similar to the shared conference method with the following exceptions:

• The IP address is resolved using thebridge's hosts file which is automatically updated every 5 minutes.  This overrides any other resolution settings.
• All IRLP protocol connections are made to the host (usually localhost/127.0.0.1) that thebridge is running on.
• The connection occurs in two stages - the IRLP to thebridge stage and the EchoLink stage, where thebridge makes the ultimate connection to the EchoLink node.

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 need to be opened up in the same way that the EchoLink protocols were opened up (IRLP uses the Speak Freely protocol for its audio transport, for which an open source 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 possibility.

Conclusion.

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.

Links