[Live-devel] Updated RTSP server implementation to support multiple TCP connections per session - new experimental release

[Ross Finlayson]

(First, if you are not using a RTSP server at all in your application, you can ignore the rest of this email.)

I have made a major update to the RTSP server implementation.  A single RTSP client session (i.e, the streaming of one particular stream to one particular client) can now use an arbitrary number (>=1) of TCP connections.  E.g., there can now be one TCP connection for the "DESCRIBE"; another TCP connection for each "SETUP"; another TCP connection for "PLAY", etc.  (Of course, this applies only to RTP/UDP sessions; RTP/TCP sessions have to use the same TCP connection, from "SETUP" through "TEARDOWN".)

Similarly, a single TCP connection can now be used for more than one session (for the same client, of course).  (Despite this, our own RTSP *client* implementation continues to use a single TCP connection for each session.)

The new RTSP server implementation does this by separating 'client connection' from 'client session'.  The "RTSPServer" class now has two member classes: "RTSPServer::RTSPClientConnection" (for a single TCP connection), and "RTSPServer::RTSPClientSession" (for a single client session, possibly used by multiple TCP connections).  You can, if you wish, subclass these two classes, along with subclassing "RTSPServer" itself.

I have also improved the way that the "RTSPServer" class manages "ServerMediaSession" objects.  (Recall that a "ServerMediaSession" describes a single media stream source (possibly with 'subsessions' for audio, video, etc.), regardless of how many clients happen to be currently receiving it.)
- As before, the "RTSPServer::removeServerMediaSession()" function removes a "ServerMediaSession" object from the server, thereby making it inaccessible to new clients, but does not stop any ongoing streaming to existing clients.
- A new function "RTSPServer::deleteServerMediaSession()" removes (and deletes) a "ServerMediaSession" object from the server, *and also* stops any streaming to existing clients.
- A new function "RTSPServer::closeAllClientSessionsForServerMediaSession()" stops any streaming (for a specified "ServerMediaSession" object) to existing clients, but leaves the "ServerMediaSession" object on the server, so that new clients can still access it.
- The "RTSPServer" destructor now removes and deletes all "RTSPClientConnection" and "RTSPClientSession" objects, and thereby also stops any existing ongoing streams.  So, if you wish, you can call "Medium::close()" on your "RTSPServer" object, knowing that this will automatically stop all existing streaming, and reclaim all of its objects.

Because these changes are substantial, and possibly have introduced some bugs, I have done something unusual, by making the new source code release an 'experimental' release.  It's available at:
	http://www.live555.com/liveMedia/public/live555-experimental.tgz

Eventually, however (possibly just within a week or so), this new release will no longer be experimental; it will become the lone supported "LIVE555 Streaming Media" release.

Therefore, if you're a developer who uses a RTSP server in your application, you are encouraged to download and test the new experimental release, and report back on any problems that you might find.  Note, in particular, that if you have subclassed "RTSPServer", then you should download and test the new experimental version sooner rather than later, because the API for subclassing has changed (the API for creating new "RTSPClientSession"s has changed, and there's now a new "RTSPClientConnection" class as well).


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120726/a8b687e0/attachment-0001.html>