[Live-devel] Timeout on reception of RTSP commands

[Ross Finlayson]

> On Dec 10, 2020, at 10:01 PM, Massimo Perrone via live-devel <live-devel at us.live555.com> wrote:
> 
> I'm having troubles with a buggy RTSP server which (for reasons that I cannot control) does not respond to the RTSP OPTION command while leaving the connection opened.
> In such a case, the livemedia RTSPClient hangs up until the server responds or close the connection.

The RTSP client isn’t really ‘hanging’ here, because I/O in LIVE555-based applications is asynchronous (i.e., non-blocking).  What it is doing, however, is just sitting in the event loop, waiting for an event (in this case, an incoming response to the earlier RTSP “OPTIONS” request) that never happens.  The client will still handle any other event that occurs instead - for example, a timeout.  (See below.)


> My question is: is there a method, or a strategy to impose a timeout on the reception of RTSP command response in the liveMedia RTSPClient class ?

Yes, the way to do this is to set up a ‘handler’ function to be called after a timeout interval (of your choice).  This is done using the “TaskScheduler::scheduleDelayedTask()” function.  (There are several examples of this in the code; e.g. in “testProgs/testRTSPClient.cpp”)

Your handler function would then call:
	yourRTSPClient->changeResponseHandler(cseq, NULL);
to cancel the pending request.  “cseq” is the (unsigned) integer value that was returned by your previous call to “sendOptionsCommand()” - i.e.:
	cseq = yourRTSPClient->sendOptionsCommand( … );


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