[Live-devel] cleared up: live-devel Digest, Vol 166, Issue 2

[Victoria Federau]

Hello Mr. Finlayson,
thank you for your replay.
We will look for an RTSP 2.0 solution. At least we believe the gstreamer has it implemented. 
Thank you very much for your effort.

with friendly regards
Victoria Federau

Message: 2
Date: Tue, 5 Sep 2017 10:48:01 -0700
From: Ross Finlayson <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use
	<live-devel at ns.live555.com>
Subject: Re: [Live-devel] LIVE555- RTSP Server
Message-ID: <98B558BA-A26F-43D0-9E8D-78B57EF66405 at live555.com>
Content-Type: text/plain; charset=utf-8

> The matter is in germany you need for a good product a very high level on security. That means we need a solution for live555 server to learn SSL.
> Is there a possibility to do that? We use at this time in development the "testOnDemandRTSPServer". On your documentation you say 'no' because live555 is only a lightwight streamer.

I don?t think we say that, specifically.

But, in any case, it?s not clear exactly what you?re asking for.

It's important to understand how the IETF-standard RTSP protocol (and thus, our ?LIVE555 Media Server?, which implements this protocol) works.  RTSP uses a TCP channel for control.  RTSP commands (to the server) and responses (from the server) are sent over this TCP channel. Note that you can easily add authentication to our server implementation, so that only authorized clients (with a username, password) can access a stream.  Note the code bracketed with
	#ifdef ACCESS_CONTROL
	#endif
in ?testOnDemandRTSPServer.cpp?.  Note that RTSP?s ?digest? authentication mechanism (as implemented by our server) does *not* involve passwords being sent ?in the clear? over the TCP channel.  Even if someone were to observe the TCP channel, they could not learn passwords.

Some people have asked for the RTSP control channel to be a SSL channel, rather than a standard TCP channel - even though (as explained above) that is not necessary for authentication.  (It might prevent some ?man in the middle? attacks, however.)  Unfortunately, that is not possible in our current implementation, because sending/receiving data over a SSL channel uses completely different operations than sending/receiving data over a standard TCP channel. 

In any case, audio/video data streamed from the server is not (in most cases) sent over the RTSP?s control (i.e., TCP) connection.  Instead, this data is streamed as RTP packets (over UDP), which are not encrypted.  (An updated version (RTSP 2.0) of the RTSP protocol did add support for SRTP (encrypted RTP packets), but nobody - including us - implements this.)


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/




------------------------------

Subject: Digest Footer

_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel


------------------------------

End of live-devel Digest, Vol 166, Issue 2
******************************************