Something similar was happening in Calgary where multiple ISPs in Calgary peered through Seattle and Toronto. Luckily YYCIX was formed and it appears that things are much better now: https://yycix.ca/talks/cuug-2013-06-18/mgp00001.html

How can you detect these node transfers? I run into similar problems often with WebRTC and I have found it troublesome to diagnose

traceroute

Had the same experience in Sweden. Between certain pairs of ISPs, all traffic was routed via one of the capital cities (Stockholm, Copenhagen, Oslo), adding 10-20 ms and jitter. Solved it by setting up a VPS at a provider with good connections to all ISPs involved.

The issue with Jamulus is that it requires a central server - which means it needs to be close to everywhere . It also needs double buffering and double compression. P2P is the way forward here IMHO.

"requires a central server" is misleading. You can set up a server wherever; there's no central server. Except for the multiple-ISP issue I discussed, there's no reason access to a server is more latency than access between the "clients". The advantage of the server/client model is that the clients can be very lightweight: I personally use a Raspberry Pi 3 with an ultra-low latency DAC/ADC hat. Works fine. All the real computation is done on the server.

Well you do need to find a server midway between all the users, which is a hassle of course. I don't personally like the model either becuase it needs to decompress, mix and recomopress all the streams on the server and also needs an extra jitter buffer. The only clear benefit to it AFAIK is that it scales better for larger groups O(N) rather than O(N2)

"need to find a server midway between all the users" Nonsense. Did you read my post? The server is in Montreal; all the clients are 200 miles west of Montreal in Kingston. Physical distance isn't important. What is important is ping time. When one tries to connect in Jamulus, dozens of public servers are suggested with their ping times listed. If none are suitable or one wants a private server, one can set up a server anywhere that provides good ping times to all the intended clients. In the multiple-ISP scenario I had to deal with, a server "midway between all the users" would have been useless, as would any kind of server-less topology.

"The only clear benefit to it..."? As I suggested, a significant benefit of the Jamulus model is that any of the clients can be "thin"; most of the computation is done on the server. You may be able to improve on this but disparaging it with silly criticisms isn't going to help you; there are thousands maybe millions of satisfied Jamulus users around the world.

P2P doesn't require any computation on any server - it's essentially serverless. It doesn't make much sense to me at least to need to compress everything twice and have multiple buffers AND have to manage a server.

Well if any of the O(N^2) connections has unacceptable latency, you'd understand why a server is sensible. Reducing computation won't improve latency in the connections. One has no flexibility with clients but a server can be located wherever good connections are available.

There is flexibility - in the P2P model if one of the clients has bad latency - their buffer gets increased to prevent drop outs. How is a server better in this scenario?

> P2P is the way forward here IMHO.

But if any of the O(N^2) P2P links has unacceptable latency, eliminating the server would be counter-productive because the client-to-server connection may have less latency if the server is located appropriately.

Maybe I'm missing something but A->B is likely to be faster than A->S->B ?