[Live-devel] HOW REALIZED NAT TRAVERSAL IN LIVE555
Jeff Shanab
jshanab at jfs-tech.com
Mon Aug 4 03:42:38 PDT 2014
If I am understanding the question correctly I did something similar using
live555 in a previous project. Originally this was only because the device
(Sercomm security camera) had some special code on it. I later wrote a
small app that allowed any RTSP camera inside the network to do reach out
from behind the firewall. **
Reach out via HTTP to a server on the net. This works thru nat firewall.
obscound the socket on the server end and pass it to live555 instead of
letting 555 create the socket. Start with the Options command back down the
socket and proceed normally.
A socket is a socket at the lowest level the rest is sort of a gentleman's
agreement between the two endpoints. RTSP is similar to http. As long as
you start inside the nat the return path is authorized thru the firewall.
There are high end firewalls that can block even this but they are usually
found in medium to large businesses.
** Pusher App connects to http server once per camera and maintains a
bidirectional persistent connection with 15 second keep alive. This allows
the server to send commands to app behind the firewall at any time. Kinda
"long polling".
A client connects to server via http and says I want to watch camera #1,
http server sends down the persistant http connection the request for
camera #1.
Pusher app connects to camera and gets and opens a new port to server.
Pusher app is a live555 restreamer. Client abscounds the port and passes it
to live555 on the client that now connects to the restreamer that is behind
the nat firewall.
I ran this on a rasberryPi with 4 cameras 30FPS @ D1. It used 9% CPU.
On Mon, Aug 4, 2014 at 12:50 AM, Ross Finlayson <finlayson at live555.com>
wrote:
> How Live555 client side library makes UDP ports reachable from the global
> network for incoming UDP traffic when both client and server are under NAT
>
>
> In short, it can't. RTSP works by having a RTSP client contact a RTSP
> server, to request a specific stream. If the RTSP client can't contact the
> RTSP server, either by name or IP address (because the server is behind a
> NAT and has only a private IP address), then RTSP won't work. (On the
> other hand, if just the RTSP client - but not the RTSP server - is hidden
> behind a NAT, then RTSP will often work OK.)
>
> What people usually do to overcome this is put a "LIVE555 Proxy Server" on
> a public-facing computer (i.e., one that has a public IP address), and have
> that proxy server stream from a 'back-end' RTSP server that can be on a
> private network. (If the proxy server computer can't contact the
> 'back-end' server, then instead, the 'back-end' server can contact the
> proxy server, using our custom RTSP "REGISTER" command, as described in our
> proxy server documentation: <http://www.live555.com/proxyServer/>) Then,
> clients (including those that are themselves behind a NAT) can access the
> stream via the (public) proxy server.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140804/42299a77/attachment.html>
More information about the live-devel
mailing list