If you’re on the private side of a NAT, then you can’t run a RTSP server there
and expect clients on the (public) Internet to be able to reach you. (You
might be able to get this to work in some cases, but there’s no guarantee.)
If your RTSP server is behind a NAT, then the only *reliable* way
Thanks Ross for your answer.
I am currently behind NAT as you mention. Couldn't I just use port
forwarding in order to have my server on a DMZ?
What I mean is this:
Public_IP:Port - FWD To -- Private_IP:Port
For each one of the ports mentioned above.
My clients would connect on the pub
> I have developed a RTSP server that serves unicast clients with a stream from
> a live source.
>
> I have based my development on the testOnDemandRTSPServer implementation.
>
> Over LAN everything works as expected. The problem I am having is that over
> the Internet I cannot use UDP as a tra
Hi,
I have developed a RTSP server that serves unicast clients with a stream
from a live source.
I have based my development on the testOnDemandRTSPServer implementation.
Over LAN everything works as expected. The problem I am having is that over
the Internet I cannot use UDP as a transport for
For the final time: This model of communication is not one that we support, or
endorse using LIVE555.
If you have a proxy server that cannot access a ‘back-end’ camera server (due
to the presence of a firewall), then you can instruct the camera to ‘register’
itself with the proxy server, so tha
Hi Ross,
I see that you see PUSHING as a non standard method but maybe for our case
makes senses, unless there is alternative solutions.
I will try to explain why Pushing in our case is really our main need and
would try to find a existent solution with LIVE555.
Our rtsp streams are from ³small c
