Hi I think that a better solution is to disable the liveness check. this can be easily done by calling the RTSP constructor with reclamationTestSeconds = 0; fRTSPServer = RTSPServer::createNew(*fEnv, serverPort, authDB,reclamationTestSeconds); Amit Yedidia.
________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Dan DuFeu Sent: Thursday, August 27, 2009 2:16 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] every 65 seconds,noteLiveness timeout handle causes the live555 send bye to QT,and disconnect the streaming. 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: [email protected] [mailto:[email protected]] On Behalf Of zhi sun Sent: Wednesday, August 26, 2009 2:20 AM To: [email protected] 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 The information in this e-mail transmission contains proprietary and business sensitive information. Unauthorized interception of this e-mail may constitute a violation of law. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. You are also asked to contact the sender by reply email and immediately destroy all copies of the original message.
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
