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 _______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
