[Live-devel] Liveness times out

[Craig Matsuura]

Ross,

If there are no clients (sessions) connected to the rtsp proxy, would a 
DESCRIBE command keep alive the camera better than an OPTIONS?  I have 
noticed the OPTIONS command has no Sessions attribute at times, probably 
due to no clients connected.   I have 8-9 camera's connected to the 
live555proxy and at times the liveness timer exceeds the timeout, which 
causes a camera to not stay alive even though it accepts OPTIONS 
commands.  As from what I understand and can see in the proxy code it 
uses a DESCRIBE to re-establish ability for the camera to stream (have a 
session).

I know what the standard answer is there is a bug in the camera 
firmware, but if the proxy is late in delivering the OPTIONS I don't see 
how this could be a camera firmware bug. Unless OPTIONS commands should 
fail if you exceed the timeout?  Should the connection close on the 
camera once the timeout has been exceeded?

I'm experiencing a bug where the liveness exceeds the timeout reported 
by the camera and the camera will not stream once a client connects 
(expected behavior if not kept alive).  (This is not a problem on the 
camera as I have verified if you send the Liveness within the reported 
timeout from the camera, the camera will allow sessions to connect and 
stream).

I have two solutions one I have implemented and the other is using a 
DESCRIBE when there is no session, but I have not tried the DESCRIBE, 
seemed weird to try.

My first solution was to keep track in the proxy rtsp client how long it 
takes to send out liveness (OPTIONS).  The event loop must have some 
long calls that exceed the time out of any times setup, so the OPTIONS 
command go out late causing the camera to not stay alive.  My solution 
is to time how long it takes between liveness commands and if it exceeds 
the timeout (reported by the camera) or the default of the 60 secs.  
This seems to work well, when we exceed the timeout I call the   
continueAfterLivenessCommand(-1, fServerSupportsGetParameter) method 
(using -1 to get a log message, could use 1 like the 
subsessionByeHandler() ) to reset the camera connection.

I thought a DESCRIBE might work if not in a session, but was not sure 
and it felt like a hack vs my first solution.

I think the real issue is the event loop. ( Used syslog to log all the 
verbose logs to see timestamps, this is how I caught the problem)

How do you get around the event loop taking too long once it get's to 
the alarms to process?  Currently I'm only handling 8-9 cameras with the 
proxy, but at times the timeout for the liveness exceeds the time set 
for the scheduleDelayedTask() for the sendLivenessCommand.  It seems to 
be a bigger problem for camera's on wifi with poor connectivity.  
However I do see from the perspective of the proxy it is taking 
significantly longer to send the actually OPTIONS (Liveness) than 
expected (not consistently slow).  I  have one other 
scheduleDelayedTask() that is every two seconds (but this is only done 
once).  So I doubt it is any tasks I have added.   It does appear to be 
the handlers registered or the select timeout is way higher than the 
timeout required for the alarms.

Thanks,
Craig

Thanks,
Craig