Tony Mountifield

Yes, you're absolutely right. I hadn't thought through that particular scenario completely, and your explanation makes perfect sense. So if the server is behind either a NAT, or a non-translating firewall that only allows inbound packets for established sessions, a client with randomised source ports will only be able to connect if that server also has the inbound port directly enabled and forwarded. If a server is behind a firewall that randomises source ports, it's even worse, as even if it has...

I have a tp-link Archer C20 router with upnp enabled. Nothing in Jamulus makes any use of UPNP, so it doesn't matter for Jamulus whether UPNP is enabled or not.

I can't think of a reason for a client not to work when it is behind double-NAT (e.g. CGN or a router behind a router). It should be able to connect to a server that is elsewhere, even if that server is behind a single NAT (without port randomisation). But being behind double-NAT would definitely make it difficult or impossible to run a server locally and have it reachable from clients elsewhere. It may be possible for such a server to register with a central server, but the other clients will probably...

I can't think of a reason for a client not to work when it is behind double-NAT (e.g. CGN or a router behind a router). It should be able to connect to a server that is elsewhere, even if that server is behind a single NAT (without port randomisation). But such a situation would definitely make it difficult or impossible to run a server locally and have it reachable from clients elsewhere. It may be possible for such a server to register with a central server, but the other clients will probably...

Good detective work. The only bit I wanted clarification on is "The WAN side of [computer B's] NAT does not have a public WAN IP." Do you mean the WAN side has another private address, such as 10.x.x.x or 172.16.x.x, etc.? And when you run a server on computer B, and view it in Explorer, what IP does it show? That must be a public IP. You probably also find that both the port and port2 values are different from the port assigned to the Jamulus server on computer B. My guess is that computer B's ISP...

Hi Diego, softins here... Firstly, if you always intend to have your server registered to a central server, you don't need any port forwarding, due to the magic I described to you on github. But if you want your server to be private and unregistered, so that you just give the IP and port number to your friends to connect, then you do need the port forwarding, as the magic doesn't happen. The Jamulus Explorer back-end behaves just like a Jamulus client when it fetches the server list and the details...

VOTE: llcon

Yes, I also found that 64 is quieter than 128, and 256 is louder that 128. This was using 3.5.0 client on a Macbook with a UMC404HD, and talking via my own 3.5.0 server on AWS. Not sure why the change in volume, but maybe needs investigating. I assume it's something to do with the codec.