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-boun...@ns.live555.com [mailto:live-devel-boun...@ns.live555.com] On Behalf Of zhi sun Sent: Wednesday, August 26, 2009 2:20 AM To: live-de...@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
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
