jacktrip hub server and clients behind (same) NAT

[Miha Valencic]

Hello!

I'd like to better understand the communication architecture and I'm having trouble finding documents with regards to ports used and for what purpose.

Some time ago, I did find a document that described 4464 and 61000 ports but can't find it anymore (perhaps CCRMA site, or github.io, don't know :)). Pointers appreciated.

Anyhow, the issue I'm having is having a remote jacktrip server in hub mode working as expected, which is super-nice. But when the clients are connecting from a network with the same "public IP", only one client can stay connected. I'm assuming this has something to do with how the ports are being handled, specifically port 4464.

To illustrate what I mean (hopefully this ASCII art will come across :)):

                            ┌───────────────────┐
                            │   Jacktrip server │
                            └───▲────────▲──────┘
                                │        │
                                │        │
                                │        │
                    Firewall    │        │
       with single public IP    │        │
────────────────────────────────┼────────┼───────────────
                                │        │
                                │        │
    ┌───────────────────┬───────┘        └───┬───────────────────┐
    │  Client 1         │                    │   Client 2        │
    │  e.g.192.168.0.10 │                    │   e.g.192.168.0.20│
    └───────────────────┘                    └───────────────────┘

For instance, I connect Client 1  using "jacktrip -C server.example.com -K Client1" and then issue similar on Client2. 

The instant Client2 connects to the server, the client1 gets disconnected:

Peer Stopped
Stopping JackTrip...
sending exit packet
JackMachSemaphore::TimedWait name = js501.server.example.com usec = 9223372036854775807 err = (os/kern) aborted
SuspendRefNum error
JackClient::Execute error name = server.example.com
JackTrip Processes STOPPED!

If Client 1 and Client 2 don't share the same public network, it works flawlessly. 

Thanks,

 Miha

[Miha Valencic]

So I found this in some (old?) docs: https://ccrma.stanford.edu/docs/common/IETF.html

In hub mode the hub server always listens on TCP port 4464 for clients newly wishing to connect. New clients perform a handshake via this TCP port, during which the hub server allocates a unique UDP port for the client to use to send audio to the server. This UDP port is normally in the range from 61002 to 62000. (The server hands out UDP ports sequentially starting from 61002, so for example if there are four clients then the server will use ports 61002, 61003, 61004, and 61005.)

Which probably means that clients connecting to server (-C) behind a firewall should work, right? What's puzzling is that the client seems to be receiving audio via UDP 4464, which won't work with multiple clients behind a same firewall. Is this the case?

A hint from jacktrip output:

UDP Socket Receiving in Port: 4464

Puzzled, I am :)

[Dave Adams]

From device "advanced settings" at app.jacktrip.org:

"Each JackTrip Device on the same local network must use a unique port number..."

I believe folks tend to assign these "10" apart (4464, 4474, etc.)

Have you tried that?

[Miha Valencic]

OK, that makes sense. I didn't check the app.jacktrip.org site - it looks it is behind a login

I'm waiting for the infra guys to open up the firewall ports so I can try that - but how does that work with the hub mode? Do individual jacktrip instances still connect automatically to one-another and mix the outputs? (hub auto patch mode 2)?

Thanks,

 Miha.

--
You received this message because you are subscribed to a topic in the Google Groups "jacktrip-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jacktrip-users/25qZXaQWDB4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jacktrip-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/9c3c8467-d8d7-4b40-b0fe-28e09cadf332n%40googlegroups.com.

[Dave Adams]

I have near zero experience with hub mode (I think I tried it by accident one time.)  Client<->Server has worked well for me (as it does for jacktrip.org.)

The account at jacktrip.org is free, as are very small virtual servers, and private servers. 

I suspect you will find it helpful to look at the ways jacktrip.org used jack features to make a system that minimizes system administration for the users (such as this arcane port swap.)

When I first started I tried my own devices, with a server on an old MacBook.  I ended up doing all kinds of WireShark and firewall log and rule work.  Life got a good deal simpler with app.jacktrip.org, except for firewall accomodations.

Final note on hub mode: I suspect that the port assignments are even more significant if there is any peer-to-peer going on.  I would HOPE that would not include mucking about with the higher number ephemeral UDP ranges (6xxxx)!  I lost my WireShark traces long ago.  I seem to recall that jacktrip really needs a firewall with some kind of "stateful inspection," so that the UDP addresses could be safely associated with legitimate requests from the "safe" side of the firewall. 

Once your team puts the rules for 4474 in place it will be interesting to see how that pans out.  If it does not work can you enlist their aid in doing a trace of what is being thrown to the firewall and coming back?

[Miha Valencic]

Dave,

thank you very much for your insight! The team has opened the ports and clients behind a same firewall can now connect without problems (I tested with two of my computers and I'm assuming more should work too). The hub audio patch mode does not work, but that can be overcome with manual patching within jack itself.

I will be sure to try out the app.jacktrip.org as well as that might be very useful.

For the current project, we developed a "server recorder" for connected clients and we plan to test it later this week to see how it goes. Normally, "users behind the same firewall" issue wouldn't be an issue at all, but when you're testing and gathering multiple users in the same room, that happens. One would ask the question of why using jacktrip if they're all in the same place, right? It is just for testing... :)

Thanks,

 Miha.

To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/1dde2a59-c84c-4dc7-8280-21758473fd8en%40googlegroups.com.