You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the growing use of Hamnet, in the case a reflector is used by multiple repeaters behind the same backhaul link, the traffic of the return channel will be carried multiple times.
To keep backwards compatibility with clients that are hosted on unicast-only networks (some repeaters reaching the rest of the reflector members through the internet for instance), it seemed advisable to keep the current reflector topology.
An alternative to that architecture, that we ditched, consists in setting up a bi-directional multicast group on the network without a svxreflector, then to set up unicast bridges at each network edge. The advantage would be an a-centered topology with improved resilience, but this comes with the cost of higher network configuration complexity, in addition to the multiple unicast bridges needed (which is why we ditched this idea).
Our current proposal is:
To update the way a svxlink client binds to a reflector to request either a unicast or a multicast return channel for the audio content. This is done to enable remote clients to still be able to bind from a network on which only Unicast is supported. The choice to request either the Unicast or the Multicast return channel is left to the client's system operator, in the configuration. (MULTICAST=1 option in the config?). In the case the multicast return channel is requested, it might be a good thing if svxreflector answered with the IP and the port of the multicast group the client will need to subscribe to. This enables the svxreflector administrator to change the multicast group without having to reconfigure each client.
To add the necessary configuration features to svxreflector to send the audio stream on a multicast channel.
To handle the case where a svxclient requests to bind to a reflector using the multicast return channel when the latter hasn't been enabled on the reflector (example: returning 0.0.0.0 on port 0, which would then be colloquially understood that no multicast group being available, and that the client SHALL fall back to a unicast binding request).
The text was updated successfully, but these errors were encountered:
With the growing use of Hamnet, in the case a reflector is used by multiple repeaters behind the same backhaul link, the traffic of the return channel will be carried multiple times.
To keep backwards compatibility with clients that are hosted on unicast-only networks (some repeaters reaching the rest of the reflector members through the internet for instance), it seemed advisable to keep the current reflector topology.
An alternative to that architecture, that we ditched, consists in setting up a bi-directional multicast group on the network without a svxreflector, then to set up unicast bridges at each network edge. The advantage would be an a-centered topology with improved resilience, but this comes with the cost of higher network configuration complexity, in addition to the multiple unicast bridges needed (which is why we ditched this idea).
Our current proposal is:
The text was updated successfully, but these errors were encountered: