I can’t understand how NAT piercing works in RTSP (or how to bypass it correctly)?

Question

Qt

Greetings!
I'm trying to make a client-server RTSP protocol.
Looking at the exchange logs between the camera (the camera acts as a server) and the client (the client is now VLC), I see something like this:
There are two protocols, one transport (UDP), the other command (TCP).
The client makes a command protocol request to start data transfer (SETUP), where it indicates its internal IP and UDP port (client_port 2200) on which it expects this data.
The server in response gives him some client_port (for example 5200) and server_port (for example 3005)
I can’t understand where the server takes the client_port from, because it is necessary that the client behind NAT initialize the transfer, but UDP is not yet configured at this moment. Also what does the server output in server_port ?
I torment Google, but these moments are not discussed.
PS if not behind NAT, then the client in the request and the server in the response have the same client_port.

Answer 1

Good day.
When I was forwarding a video stream through NAT, I found out that there are 2 types of broadcasting there, one via UDP, the other via TCP.
Using UDP, the camera sent a bunch of some packets to server_port (perhaps thereby trying to make a hole in the nat), in response, the camera started sending a video stream. It looks like UDP is being opened from the camera side as well, not just from the client. As well as the simplest workaround - switch to TCP (if the camera supports) - at least this is what VLC does when it sees that there is nothing on UDP. client_port for the server may mean, for example, for another type (unicast/multicast). I did not write very clearly, because I did not fully understand, sorry. I would be glad if you understand and comment.