> We rely on a now-ancient version (2009-09-04) of LIVE555 Streaming Media > library as the basis for the RTSP streaming server in our [open source] > product. I'm trying to assess how feasible it would be to upgrade to the > latest version of LIVE555 in the near future.
You should definitely upgrade. Not only do we not support old versions of the code, but (most importantly) newer versions fix several, often-important bugs, including security vulnerabilities. You are putting your system at great risk by continuing to use an old version (especially such an old version) of the code. (Once you’ve upgraded your open source product to use the latest version of the LIVE555 code, please let me know, and I’ll add a link to your project from our web page.) > Obviously there are challenges, for example the changeover from the ancient > synchronous API to the "new" asynchronous API. You may be a bit confused here. The ‘asynchronous API’ applies only to “RTSPClient” - i.e., to the RTSP client implementation. If your system uses our code only to implement a RTSP *server*, then this has not been an issue; our RTSP server has always been able to handle multiple clients asynchronously. > As part of the product, we have a configuration section/panel that enables > administrators to see the list of "clients" connected to the server. The list > includes [for each "client"]: the client session ID, the client IP address, > the server session ID that the client is accessing, and some additional > metadata about the server session media. The administrator can choose to > "kick" (drop) client sessions if they deem it appropriate. > > In the version of LIVE555 that we're currently using, the fClientAddr and > fOurSessionId are encapsulated in a single > RTSPClientSession class. Therefore the correlation between the 2 pieces of > information is obvious, and we have no problem building the list. However, in > the latest code these key pieces of information are split between > RTSPClientSession and RTSPClientConnection. I can't see how to correlate the > instances of these classes, especially since createNewClientSession() no > longer provides the clientAddr parameter. > > So, in short my question is: how can I get the RTSPClientConnection instance > associated with a given RTSPClientSession? If it isn't possible, can you > point me to an explanation of why the design was changed in such a way as to > make it not possible. The design was changed because the old design was predicated on the incorrect assumption (one that you also made) that each ‘client session’ is tied to exactly one ‘client connection’. That is incorrect. The RTSP protocol allows a single client connection (i.e., TCP connection to the RTSP server) to be used to send commands for completely different streams (and thus different client sessions). It is also possible to use different TCP connections to send separate RTSP commands - i.e., use one TCP connection to send “DESCRIBE”; another to send “SETUP”; another to send “PLAY”, etc. - all for the same ‘client session’. It is even possible, in principle, for these requests (within the same ‘client session’) to be sent from different client IP addresses, although I don’t know if anyone actually does this. But it is possible. In short: The RTSP protocol completely separates ‘client connections’ and ‘client connections’, and our implementation now reflects this. So, you’ll see that 'client IP address' isn’t a particularly useful piece of information to have for each ‘client session’ (because it can, in principle, change, for each command). If, however, you really want to get the 'client IP address' that was used to send a particular command, you could do so by subclassing “RTSPServer” and “RTSPClientSession”, and reimplementing the virtual function that implements that particular command - e.g., "RTSPServer::RTSPClientSession::handleCmd_PLAY()”. This function takes a "RTSPServer::RTSPClientConnection*” as parameter; you could get the ‘client IP address’ from this parameter. (“fClientAddr” is actually a protected field in "RTSPServer::RTSPClientConnection”, so you would probably need to subclass that as well, in order to get access to it.) Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
