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

[Dan DuFeu]

Ross,

 

I had similar issues with QuickTime. I suspect that it is broken (no RR
packets) when using RTP/TCP.

 

My "fix" for this issue was to include the "timeout" attribute in the
"Session" field in handleCmd_SETUP().  QuickTime does not respect the 60
second default for RTSP timeout as per the RFC (section 12.37). With the
timeout attribute sent, Quicktime will send RTSP blurbs every so often
which keeps the connection alive.

 

I think we both agree that simply disabling the liveness check will
probably result in superfluous streams.

 

Dan.

 

>>>>>>>>>>>>> 

 

Index:
C:/Development/ESM2/ThirdPartyLibraries/live555/overlay/liveMedia/RTSPSe
rver.cpp

===================================================================

---
C:/Development/ESM2/ThirdPartyLibraries/live555/overlay/liveMedia/RTSPSe
rver.cpp          (revision 857)

+++
C:/Development/ESM2/ThirdPartyLibraries/live555/overlay/liveMedia/RTSPSe
rver.cpp       (revision 858)

@@ -734,6 +748,21 @@

   struct sockaddr_in sourceAddr; SOCKLEN_T namelen = sizeof sourceAddr;

   getsockname(fClientSocket, (struct sockaddr*)&sourceAddr, &namelen);

   char* sourceAddrStr = strDup(our_inet_ntoa(sourceAddr.sin_addr));

+

+             // Add the indication of timeout (from RFC 2326 section
12.37) if we are reclaiming streams.

+             // Note: Quicktime does not respect the 60 second default
RTSP timeout. It sends nothing

+             // without the timeout indication in the Session field.

+             char timeoutAttributeStr[32];

+             int timeout = fOurServer.fReclamationTestSeconds;

+             if(timeout > 0)

+             {

+                             snprintf(timeoutAttributeStr, sizeof
timeoutAttributeStr, ";timeout=%d", timeout);

+             }

+             else

+             {

+                             timeoutAttributeStr[0] = '\0';

+             }

+

   if (fIsMulticast) {

     switch (streamingMode) {

     case RTP_UDP:

@@ -742,11 +771,11 @@

                  "CSeq: %s\r\n"

                  "%s"

                  "Transport:
RTP/AVP;multicast;destination=%s;source=%s;port=%d-%d;ttl=%d\r\n"

-                 "Session: %d\r\n\r\n",

+                 "Session: %d%s\r\n\r\n",

                  cseq,

                  dateHeader(),

                  destAddrStr, sourceAddrStr,
ntohs(serverRTPPort.num()), ntohs(serverRTCPPort.num()), destinationTTL,

-                 fOurSessionId);

+                 fOurSessionId, timeoutAttributeStr);

         break;

     case RTP_TCP:

         // multicast streams can't be sent via TCP

@@ -758,11 +787,11 @@

                  "CSeq: %s\r\n"

                  "%s"

                  "Transport:
%s;multicast;destination=%s;source=%s;port=%d;ttl=%d\r\n"

-                 "Session: %d\r\n\r\n",

+                 "Session: %d%s\r\n\r\n",

                  cseq,

                  dateHeader(),

                  streamingModeString, destAddrStr, sourceAddrStr,
ntohs(serverRTPPort.num()), destinationTTL,

-                 fOurSessionId);

+                 fOurSessionId, timeoutAttributeStr);

         break;

     }

   } else {

@@ -773,11 +802,11 @@

                       "CSeq: %s\r\n"

                       "%s"

                       "Transport:
RTP/AVP;unicast;destination=%s;source=%s;client_port=%d-%d;server_port=%
d-%d\r\n"

-                     "Session: %d\r\n\r\n",

+                    "Session: %d%s\r\n\r\n",

                       cseq,

                       dateHeader(),

                       destAddrStr, sourceAddrStr,
ntohs(clientRTPPort.num()), ntohs(clientRTCPPort.num()),
ntohs(serverRTPPort.num()), ntohs(serverRTCPPort.num()),

-                     fOurSessionId);

+                    fOurSessionId, timeoutAttributeStr);

       break;

     }

     case RTP_TCP: {

@@ -786,11 +815,11 @@

                       "CSeq: %s\r\n"

                       "%s"

                       "Transport:
RTP/AVP/TCP;unicast;destination=%s;source=%s;interleaved=%d-%d\r\n"

-                     "Session: %d\r\n\r\n",

+                    "Session: %d%s\r\n\r\n",

                       cseq,

                       dateHeader(),

                       destAddrStr, sourceAddrStr, rtpChannelId,
rtcpChannelId,

-                     fOurSessionId);

+                    fOurSessionId, timeoutAttributeStr);

       break;

     }

     case RAW_UDP: {

@@ -799,11 +828,11 @@

                       "CSeq: %s\r\n"

                       "%s"

                       "Transport:
%s;unicast;destination=%s;source=%s;client_port=%d;server_port=%d\r\n"

-                     "Session: %d\r\n\r\n",

+                    "Session: %d%s\r\n\r\n",

                       cseq,

                       dateHeader(),

                       streamingModeString, destAddrStr, sourceAddrStr,
ntohs(clientRTPPort.num()), ntohs(serverRTPPort.num()),

-                     fOurSessionId);

+                    fOurSessionId, timeoutAttributeStr);

       break;

     }

     }

 

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Thursday, August 27, 2009 12:30 PM
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.

 

	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);

 

Yes, disabling the liveness check will work.  However, it would be
better to figure out exactly why the server is not detecting your
client's 'liveness'.  I suspect that the server is not receiving RTCP
"RR" packets from the client.  You should figure out why.  (Note that if
it's because your client is not *sending* RTCP packets, then your client
is broken, because RTCP is a required part of the RTP/RTCP standard.)

-- 


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

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