On 30.12.2020 10:56, Toussaint OTTAVI via 44Net wrote:
VoIP, digital modes, SDR and other applications using computers are enjoyed by many people, particularly the young ones. The most recent commercial transceivers are SDR (ie, a computer), have Ethernet ports, and use IP. On the other hand, we own a dedicated IP range. My opinion is that every HAM application using IP should use AMPR addressing, or should be able to use it easily. If we have a good routing policy, this would allow to isolate what is pure ham radio (for ex, remote rig control) from what is general purpose Internet. AMPRNet should work as a corporate network, allowing members to communicate with each other, and with the ability to limit / control gateways to wild Internet (required by some regulations in some countries; this would help us achieve this goal)
Yes, this is exactly the kind of use that brings out the advantage of having a dedicated IP subnet available: there is a certain degree of trust between those hosts.
Now regarding that voip use and the masquerade, from my point of view as a non-US user...
Most of the people using DMR/D-Star/C4FM and whatever other digital modes are NOT in the 44net and don't want to be. They just want a simple solution for their hotspots and repeaters that needs to run over regular internet connections with a dynamic IP and not bother with other network stuff. In this case, a reflector running on a public IP or on a BGP announced 44net will provide the same job, with the same latency and the same availability, being functional equivalent.
But if that reflector sits on a meshed/tunneled host, that is no longer the case. It will need to run via the amprgw, which is not desired, so this is out of the question, especially for users and hotspots outside the US, since it will add 2 hops over the pond, which take time. For such cases, running the reflector on a public IP makes sense.
From the users point of view, the issue is similar. Running the client on a 44net address in the current meshed gateway system will send them directly to the reflector if the reflector sits on a 44net address AND provides mesh access, but usually will take them via amprgw if the reflector is only on a BGP announced subnet without tunnel endpoints (and this is the usual case as BGP announced subnets are chosen for the exact reason of not doing the mesh part). For a reflector located on a public IP, when using 44net in a meshed GW, depending on the setup, this will either masquerade the outgoing connection to the GW's public IP loosing the 44net source address (and I think this is the proper way to do it), or it will go via amprgw, again crossing the pond once or twice, depending on the reflector's location.
So, while there is no big difference in hosting a voip reflector on a public or BGP-announced IP for a regular internet user (most of the hams), it makes no sense to host it solely on a 44net meshed host (unless access via the public IP is also provided). And in this case, that reflector needs to appear under 2 different names with different IPs, so that the end user may select the one appropriate for his setup, since there is no way to provide IP information for a dual hosted reflector to the current client hotspot/repeater softwares. It is only a single name with a single IPv4 address.
And it makes also no sense for a client to try to access reflectors on the public internet using meshed 44net addresses: masquerading to the users public GW address will yield better results providing direct connections without passing through the amprgw, which will happen if access from a 44net meshed IP to a public IP is requested.
Maybe now I made my self clear...
Marius, YO2LOJ