[Live-devel] every 65 seconds, noteLiveness timeout handle causes the live555 send bye to QT, and disconnect the streaming.

[Dan DuFeu]

Hi,

 

I believe the proper fix for this issue is to add a timeout=xxx to the
session field in the RTSP response. If you turn off reclaiming sessions,
you might run into performance/memory issues.

 

I wrote a note about this on Aug 6 and included a change in a patch with
my alternate RTSP over HTTP server code.

 

Regards,
Dan.

 

>>>>>>>>> 

 

3. Added ";timeout=xxx" to the Session field. It is optional in the RFC,
but Quicktime was not respecting the 60 second default and currently if
(reclaiming is enabled) the sessions timeout with Quicktime unless this
is specified.

 

 

 

 

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of zhi sun
Sent: Wednesday, August 26, 2009 2:20 AM
To: live-devel at ns.live555.com
Subject: [Live-devel] every 65 seconds,noteLiveness timeout handle
causes the live555 send bye to QT,and disconnect the streaming.

 

Hi All,

 

I am porting live555 to our device, it works fine, but with problem:

 

Almost every 65 seconds, noteLiveness timeout handle causes the live555
send bye to QT. I notice that it caused by 

 

void RTSPServer::RTSPClientSession
::livenessTimeoutTask(RTSPClientSession* clientSession) {
  // If this gets called, the client session is assumed to have timed
out,
  // so delete it:
  
#if 1
//#ifdef DEBUG
  fprintf(stderr, "RTSP client session from %s has timed out (due to
inactivity)\n", our_inet_ntoa(clientSession->fClientAddr.sin_addr));
#endif
  delete clientSession;
} 

 

The RTCP package trace indicate there is no problem. The liveness
timeout happens since there is no RTSP request from client for a while
(fReclamationTestSeconds).

 

This probelm happend on our device, I cannot verify this problem on
linux since there is no live h264 stream, but it looks like to be the
logical of source code.

 

is it by design, or anything I missed?

 

Thanks,

-zhisun

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