hosting Information
Network Hosting
Want an Australian presence for your network? Add extra modes to your network? Or perhaps got an idea for a new network that's starting from scratch, and want somewhere to host it? If interested, contact me, Tony VK3JED, via email (I'm current on QRZ), or use the contact form on this site.
Technical Considerations
The Australian Multimode Network can use most of the common VoIP/RoIP protocols to bridge in external networks. Which protocol used depends on a few factors. Here's some pros and cons of different protocols.
USRP
USRP is the best choice when bridging in multimode hubs. With USRP, it's possible to create near optimal bridges with superior audio quality. USRP bridges require manual configuration and a static IP address on both ends. As they run raw PCM, they have the highest bitrate and don't degrade the transmitted audio. USRP links also preserve callsign metadata, which can propagate between sites and different modes. The number of available USRP links is limited only by available resources. If possible, USRP is the recommended protocol, if there's no other significant considerations.
SvxLink/SvxReflector - NEW!
Some networks are bridged to the network's own SvxReflector. This will allow sites (typically repeaters and simplex RF links) to use SvxReflector as a linking medium, if they run SvxLink. The SvxReflector requires version 2.0 of the SvxReflector protocol, which supports talkgroups. There is currently no provision to support version 1.0 of the protocol. The bridge is configured to use the Opus open source codec at a fairly high bitrate of 20kbps for good audio quality. SvxReflector can be used on demand, as a place to idle when no one is using EchoLink on your system, or as a permanent link.
Alternatively, if you have a repeater or simplex link that you wish to make a permanent part of one of the hosted networks and have a static IP address, you can use remotetrx on your repeater, to link to the instance of SvxLink on the system, which hosts the network you wish to be a part of. If you don't have a static IP, use the SvxReflector instead.
In the future, consideration will be given to adding TETRA support to SvxLink, once technical and administrative details are worked out.
As of September 2023, the Pride Network and M17 Network support SvxLink and SvxReflector. Other hosted networks can be added if there is demand.
AllStar
AllStar is fairly simple to setup, and a dedicated link can be configured using a startup macro. The downside is that callsign metadata won't propagate through the AllStar link. Audio quality is excellent, if G.711u or G.711a are used. AllStar is a good choice for bridging in other networks based around AllStar or IRLP/EchoLink with an AllStar node.
RTP
RTP is normally used only in specialised setups, typically to bridge in EchoLink conferences or IRLP reflectors. Audio quality depends on the codec chosen - for IRLP, G.711 (ULAW) is recommended, for EchoLink, either G.711u or GSM are recommended. RTP will only be offered where required, because there's a number of technical restrictions that can complicate implementation. An alternative system that uses USRP instead of RTP for bridging to IRLP and EchoLink is under development and undergoing testing.
EchoLink
EchoLink can be used as a bridging protocol under some circumstances. Like AllStar, this can be a good choice for ad-hoc bridging, albeit with lower audio quality, due to the GSM codec.
DV Modes (M17, DMR, Fusion, NXDN, P25, D-STAR)
The DV modes use very lossy vocoders and can significantly degrade the transmitted audio. They are only recommended where the external network is primarily based around a particular DV mode. The upside is that callsign metadata is usually preserved across modes. Note that D-STAR links or a D-STAR endpoint will require a hardware vocoder on a Linux host, which you will need to provide and make available on a static IP address. Some simple (apt based) software installation will be required as well.
Transcoding XLX reflector
While transcoding XLX reflectors can be bridged by using one of the supported protocols (YSF or DMR recommended), this will cause degraded audio on some paths, because XLX can introduce an additional stage of transcoding. The design of XLX reflectors doesn't permit access to PCM audio (without modifying the source code), which is preferred for optimal bridging. An alternative to xlxd that may be suitable for some setups is urfd, which offers more protocols, including the ability to link a module using USRP.
Single mode XLX reflectors can be bridged using the same mode as the reflector uses on the module to be bridged.
Want an Australian presence for your network? Add extra modes to your network? Or perhaps got an idea for a new network that's starting from scratch, and want somewhere to host it? If interested, contact me, Tony VK3JED, via email (I'm current on QRZ), or use the contact form on this site.
Technical Considerations
The Australian Multimode Network can use most of the common VoIP/RoIP protocols to bridge in external networks. Which protocol used depends on a few factors. Here's some pros and cons of different protocols.
USRP
USRP is the best choice when bridging in multimode hubs. With USRP, it's possible to create near optimal bridges with superior audio quality. USRP bridges require manual configuration and a static IP address on both ends. As they run raw PCM, they have the highest bitrate and don't degrade the transmitted audio. USRP links also preserve callsign metadata, which can propagate between sites and different modes. The number of available USRP links is limited only by available resources. If possible, USRP is the recommended protocol, if there's no other significant considerations.
SvxLink/SvxReflector - NEW!
Some networks are bridged to the network's own SvxReflector. This will allow sites (typically repeaters and simplex RF links) to use SvxReflector as a linking medium, if they run SvxLink. The SvxReflector requires version 2.0 of the SvxReflector protocol, which supports talkgroups. There is currently no provision to support version 1.0 of the protocol. The bridge is configured to use the Opus open source codec at a fairly high bitrate of 20kbps for good audio quality. SvxReflector can be used on demand, as a place to idle when no one is using EchoLink on your system, or as a permanent link.
Alternatively, if you have a repeater or simplex link that you wish to make a permanent part of one of the hosted networks and have a static IP address, you can use remotetrx on your repeater, to link to the instance of SvxLink on the system, which hosts the network you wish to be a part of. If you don't have a static IP, use the SvxReflector instead.
In the future, consideration will be given to adding TETRA support to SvxLink, once technical and administrative details are worked out.
As of September 2023, the Pride Network and M17 Network support SvxLink and SvxReflector. Other hosted networks can be added if there is demand.
AllStar
AllStar is fairly simple to setup, and a dedicated link can be configured using a startup macro. The downside is that callsign metadata won't propagate through the AllStar link. Audio quality is excellent, if G.711u or G.711a are used. AllStar is a good choice for bridging in other networks based around AllStar or IRLP/EchoLink with an AllStar node.
RTP
RTP is normally used only in specialised setups, typically to bridge in EchoLink conferences or IRLP reflectors. Audio quality depends on the codec chosen - for IRLP, G.711 (ULAW) is recommended, for EchoLink, either G.711u or GSM are recommended. RTP will only be offered where required, because there's a number of technical restrictions that can complicate implementation. An alternative system that uses USRP instead of RTP for bridging to IRLP and EchoLink is under development and undergoing testing.
EchoLink
EchoLink can be used as a bridging protocol under some circumstances. Like AllStar, this can be a good choice for ad-hoc bridging, albeit with lower audio quality, due to the GSM codec.
DV Modes (M17, DMR, Fusion, NXDN, P25, D-STAR)
The DV modes use very lossy vocoders and can significantly degrade the transmitted audio. They are only recommended where the external network is primarily based around a particular DV mode. The upside is that callsign metadata is usually preserved across modes. Note that D-STAR links or a D-STAR endpoint will require a hardware vocoder on a Linux host, which you will need to provide and make available on a static IP address. Some simple (apt based) software installation will be required as well.
Transcoding XLX reflector
While transcoding XLX reflectors can be bridged by using one of the supported protocols (YSF or DMR recommended), this will cause degraded audio on some paths, because XLX can introduce an additional stage of transcoding. The design of XLX reflectors doesn't permit access to PCM audio (without modifying the source code), which is preferred for optimal bridging. An alternative to xlxd that may be suitable for some setups is urfd, which offers more protocols, including the ability to link a module using USRP.
Single mode XLX reflectors can be bridged using the same mode as the reflector uses on the module to be bridged.
