Unable to watch RTSP stream outside of local network

[Maoration]

I'm running a simple node.js server using rtsp-streaming-server code. Server configuration: this.server = new RtspServer({ serverPort: 5554, clientPort: 6554, rtpPortStart: 10_000, rtpPortCount: 10_000, });

when the code starts, the rtsp server boots up, and also an ffmpeg process is run in the background, with the output set to the publish server: ffmpeg -re -i video.mp4 -filter:v scale=384:-1 -c:a copy -f rtsp rtsp://0.0.0.0:5554/123456

ffmpeg is running properly and without errors, i.e.- the rtsp server is 'online' and successfully listening for publishers on port 5554.

• When I run VLC on the same computer, using this network stream address: rtsp://0.0.0.0:6554/123456 everything works properly, and I see get the video stream.

• When running VLC on another computer in the home network, it's working fine- I see a video stream (but it does take a bit more time to load, and understandably, feels somewhat less stable)

The problem occurs with trying to access from outside the network.

• When running the server locally on my computer, I configured my home network router with DMZ- forward all incoming requests on all ports to the computer running the server. And indeed, when I open VLC on my mobile phone, connected to 4G (and not the home wifi) I can see logs on the server for incoming requests on port 6554 (via clientHook I added to the server config) - HOWEVER, no video is playing. I dont get any errors on the server, and the player seems to keep trying and then just stops.

• The same happens on the cloud. we have this server deployed on AWS using Kubernetes. Inbound traffic is enabled on port 6554, and outbound traffic is not limited by default. I can see server logs for incoming rtsp requests on 6554, but again, VLC (and an online RTSP player I found) cant seem to be getting a video stream. with VLC logs I'm getting this, eventually:

live555 debug: RTP subsession 'video/H264' live555 error: SETUP of'video/H264' failed 504 Gateway Time-out live555 debug: setup start: 0.000000 stop:0.000000 live555 error: Nothing to play for rtsp://PUBLIC_SERVER_ADDRESS:6554/123456 live555 error: TCP rollover failed, aborting

What am I missing? Any suggestions, test, or additional information would be much appreciated.

[chriswiggins]

Great write up of your issue!

The problem here is you’re port-forwarding the RTSP port, however RTSP uses RTP (over UDP) under the hood to stream the video, on different ports. Unfortunately this means that without some special consideration in the library, it doesn’t know how to deal with NAT.

The last log item also shows you another problem - this library doesn’t support RTP/RTSP/TCP which would get around the issue by interleaving the RTP packets in the RTSP stream.

I suggest if you need to port-forward you look into another solution. It’s a steep learning curve but we’ve recently started using gstreamer’s RTSP server which gets around all of these roadblocks

[RobotnickIsrael]

Do you have any solution for this? I don't want another docker just for connecting my ffmpeg to rtsp. This package really did a good job before kubernetes

[RobotnickIsrael]

I'm running kubernetes on multus mode, which supposed to make flat network between the pods, yet I'm facing the same issue. (TCP works but not udp) Maybe the rtp output goes from the wrong interface. Anyway to tell the rtsp server which interface to use?

[chriswiggins]

Kubernetes doesn't have networking problems with UDP if you're running pod-to-pod communication (we do this). The issue is definitely if you're trying to to push data from outside Kubernetes to inside it as port-mappings don't work properly. Inside a pod there is only 1 interface so it won't be leaving the wrong interface.

You'll have to do some deeper digging yourself into this unfortunately!

[dev-ninja-ops]

@chriswiggins @RobotnickIsrael

Hey Chris,

I'm facing the same issue...

What you wrote is inaccurate, and I will explain. In our system configuration we run over kubernetes using multus as a cni plugin.

Now, the way it works is that multus creates a SECONDARY bridged interface on top of the host's interface. It means that if you exec into a running pod, you will actually see 2 interfaces, the In-Cluster one (AKA ClusterIP) and a Secondary bridged one with the external IP (usually called net1).

Muluts is a huge enabler, because that way, If rtp is directed thorugh the secondary multus interface, we can actually route the rtp traffic outside of the cluster.

We are using it to actually solve similar issues of Outer-Cluster UDP-based communication to our customers, and it works great.

So choosing an interface would actually solve this issue.

[chriswiggins]

Wow neat! Hadn't heard of Multus so naively dismissed the idea. Apologies.

Could definitely make the library bind to an interface but unfortunately not something I have time for at the moment.

If anyone wants to flick a PR through with the changes though I'm happy to check it out

[RobotnickIsrael]

Hi @chriswiggins I tried to build the project but i'm keep getting "Successfully compiled 0 files with Babel (10ms)" after npm run build. no js files on build directory. Am I missing something? (no errors on npm build. I didn't even get to change anything in the src)

[chriswiggins]

@RobotnickIsrael please open a new issue for something unrelated - but I can confirm that this is working fine on my end. What version of node are you running?