home
The EchoCloud Network
Information on the Australian/Irish IRLP/EchoLink Amateur Radio Network.
Summary:
The EchoCloud is a series of interconnected IRLP reflectors and EchoLink conferences. The purpose of the network is to enable communication around Australia and encourage amateurs to talk. All stations are welcome to connect, whether in VK, Ireland or elsewhere. This is the backup information site, when http://www.echocloud.org is down. Visit http://www.echocloud.org for more information about the network and its users.
Key systems:
The main systems that form the backbone of the network are:
IRLP Reflector 9500 (ADPCM), Sydney, Australia (disconnects between 8PM Friday and 3AM Saturday for IRLP Virtual Pub)
IRLP Reflector 9550 (ADPCM), Adelaide, Australia (disconnects between 8PM Friday and 3AM Saturday for IRLP Virtual Pub)
IRLP Reflector 9559 (GSM), Adelaide, Australia
EchoLink Conference *AUSSIE*, Adelaide, Australia (All inter-system links terminate here)
EchoLink Conference *IRELAND*, located in Ireland.
AllStar node 2199, Melbourne, Australia (to be relocated to Adelaide) - Gateway to the AllStar network of Asterisk based systems. AllStar is currently offline.
Regular systems:
There are a number of EchoLink conferences which participate regularly on the network. Some are connected almost, but not quite 24x7. These systems often disconnect for local traffic peaks or to avoid causing interference to Australian peak traffic. The known regular participating conferences are:
*ULSTER*
In many cases, the sysops of these conferences are also part of the admin team for the entire network.
Usage Guidelines:
Note that these are guidelines only. We would like to keep the network open and free of politics or draconian rules. With your help, we can keep this relaxed policy going.
All amateurs from anywhere in the world are welcome to connect to the network, and we have many regular participants from around the world. Stations may connect using RF links or directly from their PC (EchoLink only). There are no restrictions as to the type of station that can connect, or where they are from.
Choosing a conference -
On IRLP, there's a couple of considerations. If your node uses dialup, you will only be able to connect to 9559, otherwise you may use either 9500, 9550 or 9559. Occasionally, an IRLP node may behave strangely when trying to use GSM coded audio. If you find you have issues such as unexpected audio dropouts on 9559, give 9500 or 9550 a try instead. Where possible, 9559 is suggested, unless you want to automatically join the VK Virtual Pub on Friday evenings (Sydney time).
On EchoLink, Australian stations should use *AUSSIE* . *AUSSIE* now uses the conference kicker script, so make sure you're not connected to anyone else while you're connected to *AUSSIE*. :) *IRELAND* is the recommended place for European EchoLink users. Again, *IRELAND* has its own system for preventing stations in conference connecting. Stations in the US and other parts of the world can try either *AUSSIE* or *IRELAND*, and see which works best for them.
Muting, Kicking and Banning -
We only mute or kick stations when they interfere with the proper operation of the network. If you are muted, you are welcome to disconnect and reconnect when you have fixed the problem. If we are aware by other means (e.g. the text box, email or other communications) that you've fixed the problem, we'll remove the mute at the earliest possible opportunity. Disconnecting and reconnecting from the conference will reset the mute condition. If you have been kicked, feel free to reconnect, once you've resolved the problem. Stations with particularly severe problems may be banned, until they can resolve the issue. Banning is used only as a last resort.
Note for AllStar users -
AllStar users should note that the current AllStar technology plays the connect and disconnect messages to everyone on the conference, which could cause problems. If you are connecting from an AllStar node to 2199, please keep the number of connections and disconnections to a minimum. In other words, it's better to stay connected than disconnect and reconnect a few minutes later. We're still new at the AllStar/Asterisk game, so if anyone knows how to suppress those messages on chan_rtpdir, we'd like to know! I believe newer versions of app_rpt are able to suppress the connect/disconnect messages on VoIP links. This configuration will be used, when AllStar support is re-enabled (hopefully in 2010!).
Conferencing -
We recommend that individual EchoLink PC users and RF links (-L and -R stations) disable conferencing while connected to the network. This can be done manually, or you can simply uncheck the "Allow Multiple conferences" checkbox in your EchoLink setup. This configuration will allow more than one station to connect to you when you're not connected to a conference. If you have friends who wish to join the conference, just get them to connect to one of the key systems above. This makes the network easier for us to manage. It also means that if your friends or other connecting stations have a technical hiccup or do something silly that interferes with the network, you won't get muted or kicked for their mistake! Also, connecting to multiple stations increases the risk of creating a feedback loop.
Other conferences (i.e. not PC users or -L/-R links) are welcome to connect to the network, if a large percentage of the userbase are keen to join in. However, we do encourage users to connect directly to our primary conferences where possible.
There are a small number of stations that insist on connecting to as many other EchoLink systems, including conferences, as possible and then conducting a DX net. This practice is not allowed on the network, and anyone found to be doing this will be given a friendly warning to stop, and some advice for using the network. If they do not heed the warning, they will be banned from connecting to any of the primary or regular systems in the network.
Note that *AUSSIE*, and *IRELAND* only allow individual stations (including -L and -R) or specifically approved conferences. All other conferences or stations in conference mode will be disconnected automatically. If you have a conference that you would like to link to *AUSSIE* full time, please email vk3jed@vkradio.com with your details. We will consider your request, and if approved, add your system to the allowed conferences list. Only conference stations running thebridge or thelinkbox by WB6YMH will be considered for connection to *AUSSIE* at this time. This is because this is the only conference server software we know of that is compatible with our administrative interfaces.
Gateways to foreign networks -
We welcome gateways to foreign networks. It is best these are connected directly to *AUSSIE*. Gateway systems should not allow conferencing on the EchoLink side. Conferencing on the foreign network side is welcome.
Gateways should adhere to the following:
- Use a digital link between the foreign network and EchoLink/IRLP, where possible. Digital linking results in higher audio quality and lower latency through the gateway. Analogue gateways will be considered on a case by case basis (generally only where a digital alternative is not available). Currently, digital linking solutions exist for IRLP (both ADPCM and GSM), D-STAR (DPlus and dExtra) and Asterisk/AllStar.
- Due to Australian regulations, gateways that link to D-STAR will not be permitted to link to our network, as it is impossible for us to ensure that any connected Australian D-STAR gateways don't accidentally breach their licence conditions.
- Ensure you have permission to link your gateway to EchoLink. Normally, gateways from networks that allow direct PC access are not permitted under EchoLink's access policies.
- The gateway must not allow non amateur access to the system. This is to comply with EchoLink access policies and Amateur regulations around the world.
- Because our network is based in Australia, and we want to ensure that all Australian amateurs can use the system, please ensure all endpoints on your non EchoLink network can be utilised by Australian Foundation licensees. In practice, this means that the RF nodes on Australian soil can only run FM on 10m, 2m or 70cm or SSB on 80m, 40m, 15m, 10m, 2m or 70cm. We are not concerned with what frequencies or modes nodes located outside Australia operate on.
- Ensure that nodes on the non EchoLink side of the gateway meet the standards of good practice as outlined under Technical Considerations below. If your gateway causes too much interference, we will have to remove it from our network.
Thoughts for software developers:
If you develop software for amateur VoIP linking, please consider the possibility of allowing your system to be interconnected to other software using open, standard protocols, and an open and supported codec. Some ideas include:
- Transport protocol can be RTP, Speak Freely or IAX2. The latter has the advantage of having full control signalling, trunking and authentication.
- Support one or more of the following audio formats - GSM, ADPCM, uLaw or 16 bit PCM. GSM is best for direct connection to EchoLink, as no transcoding is required. ADPCM is good for IRLP, as most of IRLP uses ADPCM. uLaw and PCM are usually a good choice for linking to networks that use none of the above codecs.
Language -
The EchoCloud services a mostly English speaking userbase. If you wish to hold a conversation in another language, we would prefer if you connect to the other station(s) direct, or move to a conference more appropriate for the language you are using. While many people speak more than one language, English is the only one that everyone is likely to understand. Also, if you are conducting a QSO in another language, PLEASE identify in English, as this makes it easier for our RF links to comply with regulations in English speaking countries.
Local QSOs -
If you're conducting a local QSO on one of the connected nodes, please consider disconnecting from the network, unless you intend for others to join the QSO. If you remain connected while conducting a local QSO, PLEASE wait at least 5 seconds between overs. This gives others from remote systems time to break in and join your QSO or make contact with another station.
Nets -
Nets are generally frowned upon. The network is intended primarily for ragchewing. There is plenty of spare capacity for nets on IRLP and EchoLink at the Adelaide site. The *VK3JED* (IRLP 9558) conference is dedicated to nets. While prior permission to run nets on *VK3JED*/IRLP 9558 is not required, I recommend you email me at vk3jed@vkradio.com, if you would like to run your net on *VK3JED*. That way, I can guarantee you a timeslot, and your net will be publicised at http://ref9550.vkradio.com .
Pause, Pause, Pause-
Please leave long pauses (at least 3 seconds) between overs, even while communicating with stations across the network. Again, this gives others a better chance of joining in the fun. Also, when first connecting to the network, please wait at least 15-30 seconds before transmitting. You may have connected in between other peoples' overs. The long wait ensures that the system is free before you call.
Text box users -
Clutter by automated messages is becoming an increasing problem in the EchoLink text box. Remember that every connected EchoLink system will see what you or your system puts into the text box. With dozens of connected systems, this can get cluttered very quickly. If you can disable your automated announcements, please do. Also note that the majority of our users are on RF links, so notices such as "Please leave 4 seconds between overs" or "please unkey or be muted" are actually not very useful, since the RF users can't see them.
Please keep the text box content appropriate for Amateur Radio. Some RF links use TTS (text to speech) to read the contents of the text box over the air.
Technical considerations -
This section is for RF link and especially repeater owners on both IRLP and EchoLink. While we don't kick or mute nodes, unless they are seriously degrading network performance, we do ask that all link and repeater owners try and make their systems as "network friendly" as possible, in order to create the best user experience. The following paragraphs outline the ideal to aim for.
There is one golden rule for designing an RF link. That rule (and the goal that link owners should aim for) is:
"No audio shall pass to the Internet, unless someone is actually talking on your system's input frequency".
What does this mean? Basically, that no extraneous traffic such as repeater tails, Morse or voice IDs, courtesy tones or other announcements should be passed to the other nodes on the network. There is one exception to this rule, and that is the case of an ID that occurs while a user on the input is talking - these don't adversely affect the network. The reason to aim for the above goal is that when these extraneous transmissions occur, they seriously degrade the user experience on the network. At best, they block the network, often at critical times, because these transmissions can be delayed by a few seconds - precisely the time when someone is likely to break in. At worst, if there are two or more repeaters feeding courtesy tones and/or tails into the network, they can "ping-pong" each other, rendering the conference unusable. CWIDs don't cause long term ping-pongs, but remember there can be literally hundreds of repeaters on the network. What would happen if all of them let an ID slip through every 10 minutes?
OK, so how do we fix this problem? First, how NOT to fix it. It is recommended NOT to cover the problem up using the VOX timing settings in EchoLink, or the equivalent settings in IRLP. This results in the tail being transmitted in its entirety across the network after a user on YOUR system unkeys. Your users may not be aware of the issue, and if you have two or more conducting a local QSO, they may not be leaving long enough breaks, because they're unaware what's going on. I have seen links keyed up continuously from this sort of misconfigured system. Also, these settings do not address the issue of IDs at all. However, this is still better in most cases than doing nothing.
Instead, the "quick and dirty" fix I suggest is to configure your repeater so that it encodes a CTCSS tone ONLY when there is a valid input signal. The node radio would then decode the tone. This means that as soon as the input signal drops (within a fraction of a second), then the node stops passing audio to the Internet. This completely fixes all of the above issues. Some repeater controllers can be programmed to operate this way, while other sites will need to have an outboard CTCSS encoder installed, with an enable signal derived from the repeater's COR/COS input. This solution works extremely well, is cheap, simple to implement and is the recommended option for those who can't or don't wish to consider the full duplex connections below.
IRLP node owners may wish to consider the feasibility of locating their node at the repeater site, or using a full duplex radio link. This is because IRLP has the ability to accept commands, even while the node is transmitting, if the board is appropriately configured (and your radio hardware can handle it - don't try this on a simplex node!). That way, your users can drop the link, even if there's a carrier holding the system open, or a couple of quick keying stations are tying everything up. If everything, including your PC and soundcard can handle full duplex, IRLP can even make full duplex connections with other full duplex capable nodes. Locating the node at the repeater site has little impact on the rest of the network, but it can be a nice touch for your users.
Have Fun!!! -
The most important rules are to enjoy your time on the VK Network, and to not be too easily annoyed by things that occasionally happen. The network is large, consisting of 4 major conference servers, a changing number of "satellite" conferences and dozens to hundreds of RF nodes and PC users. On a network this size, things do break sometimes, and sometimes people forget to do the right thing (we're usually too keen to hit that PTT! :-D ), and others are just finding their way around and may accidently trip up the network through lack of experience. If this is you, you won't be chastised for your mistake. Instead, we hope to be able to help you learn how to make the best use of the system and VoIP technology in general.
Last edited August 18, 2009.