The LIVE555TM Proxy Server
The "LIVE555 Proxy Server" is a unicast RTSP server
- built from the
"LIVE555 Streaming Media" software -
that acts as a 'proxy' for one or more 'back-end' unicast or multicast RTSP/RTP streams (i.e., served by other server(s)).
The key feature of a proxy server is that it reads each 'back-end' stream only once, regardless of how many separate clients
are streaming from the proxy server. This makes the proxy server ideal, for example, for streaming from a RTSP-enabled video camera
(which might not be able to handle more than one connection at a time).
--> [RTSP client1]
[back-end RTSP/RTP stream] --> [LIVE555 Proxy Server] --> [RTSP client2]
--> [RTSP clientN]
The "LIVE555 Proxy Server" is a command-line (i.e., 'console') application.
The simplest way to run it is to type:
where <url> is a RTSP URL
(i.e., beginning with "rtsp://")
of a 'back-end' stream (e.g., from a video camera).
After starting up, the server will display its own "rtsp://" URL for the proxy stream.
RTSP clients can then use this URL to play (i.e., receive) the proxy stream.
The server can act as a proxy for many 'back-end' streams - not just one.
If you enter more than one "rtsp://" URL on the command line, i.e.,
live555ProxyServer <url1> <url2> ... <urlN>
then the server will - after starting up - display "rtsp://" URLs for proxying each one.
(Of course, you should proxy multiple streams only if you have sufficient network bandwidth to receive all of them.)
Verbose (debugging) output
To display additional output, showing the basic operation of the server, add the
"-v" option, before the "rtsp://" URLs.
To display even more output
- including the RTSP protocol exchange between the proxy server and each of the 'back-end' servers -
"-V" (i.e., upper-case "V") option instead.
(If you are having trouble with the proxy server, then we recommend using the "-V" option to try to figure out what's wrong.)
Back-end streaming over TCP
By default, the proxy server will ask to receive each 'back-end' stream via UDP (i.e., receiving RTP and RTCP packets as
Sometimes, however, the 'back-end' server may be behind a firewall that blocks UDP packets.
To overcome this, you can use the
to request that each 'back-end'
RTSP server stream RTP and RTCP data packets over
its TCP connection, instead of using UDP packets.
(Note that not all RTSP servers support TCP streaming, and that
TCP cannot be used to receive multicast streams.)
You should use this option only if you are unable to receive UDP packets,
because streaming over TCP can cause incoming data to be excessively delayed.
Alternatively, you can use the
option to request that each 'back-end' stream be sent (using TCP) over a
"RTSP-over-HTTP tunnel", using the specified HTTP port number.
RTSP-over-HTTP tunneling can be useful if you are behind a HTTP-only firewall.
(Note, however, that not all 'back end' RTSP servers will support this.)
The "-t" and "-T <http-port-number>" options apply only to the
They do not affect the 'front-end' streams from the proxy server to (potentially multiple) RTSP clients.
Those streams can be over either UDP or TCP, depending upon what each client requests.
Proxying access-controlled streams
Some 'back-end' RTSP servers require user authentication (via a user name and password)
before you can access their stream.
If you add the
"-u <username> <password>" option
to the proxy server,
then it will use this
pair - if necessary - to access each 'back-end' stream.
(To specify an empty password, use
"" for <password>.)
Alternatively, you could try including the user name and password inside
the "rtsp://" URL, as:
(This is not recommended, however, because - in this case - the password will be sent in the clear
over the Internet. Also, not all 'back-end' servers will accept this type of URL.)
Proxying one or more 'advertised' back-end streams
This server application can also set up proxying for a back-end stream that's advertised using a "REGISTER"
(This advertisement - which specifies the "rtsp://" URL of the back-end stream - can be sent either by the back-end server itself,
or by some third-party application.)
To give the server application this functionality, start it with the
(If you use this option, then you may omit entering any "rtsp://" URLs on the command line.)
The proxy stream will then be accessible - from the proxy server - using a "rtsp://" URL that
will be announced on the console.
- As a special feature - if the "reuse_connection" parameter was set in the "REGISTER" command's "Transport:" header -
the proxy server gets to reuse the TCP connection on which it received the "REGISTER" command.
This can be useful if the back-end stream's server is behind a firewall or NAT, but the proxy server is run on the public Internet.
(In this case, you may also wish to use the -t option, to request that the back-end
server also send its RTP/RTCP packets on this same TCP connection.)
- "REGISTER" is a custom RTSP command, developed by Live Networks, Inc.
It is currently non-standard, but is described in an
- If you use the "-R" option, then you should also use the
"-U <username> <password>" option,
which specifies a username and password that should be used to authenticate the incoming "REGISTER" command.
(Note the difference between the '-u' command, which specifies a username and password to be used for accessing back-end streams,
and the '-U" command, which specifies a username and password to be used to authenticate incoming "REGISTER" commands.)
- The application "registerRTSPStream" - included in the "testProgs" directory - can be used to 'register' a back-end stream with a proxy server.
Source code, and support
Because this application is intended
for computer networking professionals rather than casual end users,
we do not make it available as a pre-built binary.
Instead, you must build it yourself, from source code.
To do so, you must download and build the
"LIVE555 Streaming Media" software.
Note that the "LIVE555 Proxy Server" application is included in the
Support for the "LIVE555 Proxy Server"
(and the rest of the "LIVE555 Streaming Media" code)
is provided via our developers' mailing list:
Note that you must first subscribe to the mailing list before you can post to it;
please also read the
before posting to the mailing list.
and the Live Networks logo are trademarks of
Live Networks, Inc.