Repeater Port to Link Priority and Simultaneous Call Arbitration #732
Description
On our deployment of SvxLink (24.02), there are a number of full-time linked full-duplex repeaters, and some on-demand half-duplex links all running on the same instance. What we have observed is that when multiple ports are combined in a Link, and multiple ports on that Link start receiving inbound traffic (ie. a "pile-up") then the specific port where the later received traffic was received on will repeat back outbound, but the other ports participating on the same Link will continue to carry the first received inbound traffic and not the second call. Once this second call terminates, the port will late re-join the ongoing call happening on the rest of the line, albeit with some additional latency compared to the rest of the ports.
We are looking for a way to configure this behaviour, whether it is one of the following outcomes:
- Same as current, with Local port repeat priority with other link traffic completely ignored then late re-join any other call in progress;
- Mixing all sources at their normal amplitude so that all users, regardless of which port they may be participating on, can hear that another station is attempting a call;
- Ducking (reducing the amplitude by a certain amount, but not completely muting) the other calls while maintaining local repeat at full amplitude so that the ongoing conversation takes precedence
The intent is that receiving stations can hear in the background that another station on another port, via the link was trying to call in.
Secondly, there is an application where certain ports may require administratively configurable priority. For example we are looking for a way to configure a particular port as highest priority on a given Link, where any inbound traffic received on that port will immediately pre-empt and override (mute) all other call traffic that may be occurring on the Link, outbound on all participating ports. While other ports may be assigned a lower priority, and if multiple ports are configured with the same priority they can arbitrate using the methods described in the first section above. There may also be a hang time (in seconds or milliseconds) where that higher priority continues to be reserved until the call is considered terminated and the other ports return to normal operation. This includes physical input ports as well as virtual ports such as EchoLink which may also address similar requests for EchoLink to have adjustable priority.
These functions are currently available on other repeater controller and linking platforms, and as we decommission those devices and replace with modern, open and maintainable software such as SvxLink we are running into some trouble replicating the same capabilities.
Thanks for the consideration.