Dave K9DC, K9IP - below The main pitfall with the IPIP mesh is performance. You will be dependent on unknown links, depending upon what each linker is capable of providing, most of which you will have no knowledge of, nor any ability to fix anything should you want to. VoIP does not require a ton of bandwidth. IRLP is probably the biggest consumer of raw bandwidth (highest quality). But that is only roughly 80 kbps per connection. But it does require decent jitter performance (changes in latency). No, If you announce your own prefix using BGP, your prefix is not dependent on UCSD at all. It will depend on your provider’s backbone and their bandwidth. UCSD is completely out of the loop. It is just another public IP address. VPN clients are how the 44-net connections are delivered to member clients. IRLP has chosen to use TCP based tunnels to a nearby VPN server location. Try a ping or traceeoute to stn4733.ip.irlp.net. That is a repeater in Indiana connected via AT&T Wireless cellular connection, through our Chicago hub. We also provide service through our VPN hub in Sydney, Australia. Dave K9DC, K9IP > On Jun 21, 2022, at 07:51, Ken via 44net <44net(a)mailman.ampr.org> wrote: > > Hello all, > > So I have been assigned a block of IPs and have successfully created a gateway. I am able to pass traffic trough it as expected and it works as one would expect. However... > > My intended use case for amprnet includes a lot of VOIP traffic, which as we all know is heavily dependent on latency and bandwidth. I am currrently utilizing the IPIP tunnel approach to connect my gateway into the system. > > > Thank you so much! I appreciate the opportunity given here to learn and expand my knowledge. > 73, > de KC2IDB

Basically, in a fully configured IPIP network most VOIP scenarios should work without issues. 1. The tunnel system is a full mesh, meaning that your destinations are directly reachable via the mesh. Any mesh partner is a P2P VPN, the only drawback is a slightly reduced MTU For BGP announced destinations, if you route to them via amprgw you will get a bottleneck at amprgw. If you use your public IP to reach them, sacrificing your 44net source address in the process, that bottleneck is gone. 2. If you announce your subnet via BGP, there are 2 scenarios depending on your peers configuration. It is the reverse of the situation from point 1, and outside your control. 3. VPN solutions offert no advantage over the mesh and may increase latency, but you are right, they depend on their server and networking capabilities. So if your partners are on the mesh, the mesh is the best solution. For others, your mileage may vary. But at least for BGP destinations, try to NAT to your public IP instead of tunneling via amprgw. Marius, YO2LOJ On 11/07/2022 00:50, Frederic Zulian via 44net wrote: