Over the next couple of weeks, there will be some significant changes to the https://ukwide.svxlink.net https://au.svxlink.net and the rest of the family.
The following upgrades will take place but with possibility of rollback if there is any issue.
- The following AllstarLink bridges will be enhanced with software that connects each bridge to its parent svxreflector, which means that the EASTCOAST reflector will connect directly to the North America svxreflector, along with HAMRADIO2POINT0, BLINDHAMSDNand BLUELIGHT; VK-OZHUB will connect directly to the Australia/New Zealand SvxReflector, and the OARC, ANGLOSCOT and NWAG to the UK Wide SvxReflector. The new software is a new module in asl3, that will essentially remove the need for svxlink-usrp in the bridge, as asterisk will connect directly to the svxreflector in a one-off, instead of linking multiple ReflectorLogics.
- At the same time a newly developed Federation.conf in SvxReflector part of the SvxLink V26.05.1 will be launched on the UK Wide, Australia/New Zealand and North America Reflector that will link talkgroups in a way that will permit certain talkgroups to be concurrent as a family in the other reflectors according to need. There will be local talkgroups that are unrestricted to one Reflector and Federation Talkgroups that can be shared across reflectors.
Because of the planning involved, this is going to a fast transfer of protocols, as one will not work without the other.
If the first one fails then the transfer will not take place.
If the first one works, but the second one fails, then both with be rolled back to the point at which they were not installed at all.
The good news is that I have already tested the first of the single Reflector AllStarLink talkgroups, and they are now working directly from their AllStarLink origins into the north.america.svxlink.net SvxReflector, so the transfer of the first part is almost certain.
Hopefully the final transfer if succesful will take less than 10 minutes, but the results of each transfer will be seen immediately. so interruption to service will be minimal.
Unlike Allstar nodes, the majority of users will notice no disruption, as all the nodes return to stand-alone functionality. The connectivity between nodes will be disrupted only momentarily as the reflector are restarted.
What does this mean for users and repeater keepers?
- Repeater keepers can add talkgroups to their monitoring lists that will give them universal coverage. For at the moment UK users can access 235 (UK-Wide) but not 310 (USA-Wide). While UK Users can already access Australia-Wide – this will be changed from the Current SvxLink Bridge to a [Federation] Talkgroup shared family wide. All these changes mean that for the purposes of WorldWide Communication, certain talkgroups will be shared across the Reflectors. So USA repeater can have 235 and 505, Australia users can have 235 and 310, and UK repeaters can have 310 and 505 in their respective MONITOR_TGS list. These will not be the only talkgroups, but for the purposes of a clean network, we cannot have too many talkgroups available in this fashion, but in real terms there are surprisingly only 127 talkgroups.
- Local Talkgroups will exist as they do now, and stay in the [HOME] and if there is a special case local talkgroups can be added to a federation [FAMILY] list to enable them to cross into the other reflectors.
- Talkgroups that are deemed International such as 91, 92 will be in the [FAMILY] list as well, as will the AllstarLink Bridged Talkgroups, so that they will available across the whole network. However if there is any issue this will be reviewed on an individual basis.
- These peer-policies will be stored in a .json file that will outline the permissions of where these talkgroups are {imported} or {exported} to and from.
For the administrators is will be an easy task to manage these talkgroups in Federation.conf part of an upgrade svxreflector.conf. Whilst the MCC pattern will largely be observed, there are naturally some differences with the display of some of the AllStarLink Talkgroup numbers derived from their associated AllstarLink Node Numbers.
There are some new terms that might help in understanding this concept.
[FEDERATION] is the arrangement of linking independent svxreflectors together.
[DOMAIN] is the local group, on a specific reflector for example DOMAIN = UK-WIDE, It will be globally unique and will have a REFLECTOR_ID which will be the url by which it is known. Each DOMAIN will also have a CALLSIGN which will be shared on the other reflectors NODE DASHBOARDs.
[FEDERATION_PEER] is the table of names each given to these svxreflectors that gives them that linking status.
[FEDERATION_PEER_name] will contain the connecting information of the other reflectors, that given them the ability to connect. This will be the HOST information that each node also carries, including the PROTOCOL that can be =2 or =3 to allow for differences in build. there are CONNECT controls here too.
[FEDERATION_TRUST] is the group of svxreflectors to which the current reflector may connect that list the CALLSIGNs each of the other Reflectors contain to assure security and communication.
A full implementation of talkgroup sharing such as achieved in the BrandMeister scenario, and wildcard implementation was discounted, but this may be considered later. Another software solution that offered this was discounted for other reasons, mainly due to provenance.
The solution I have implemented is based entirely on the work of Tobias SM0SVX, and has been offered back to him as a pull request.
In building this software, I completely ignored that other solution to ensure that the separation from that offering was unambiguous.