[Live-devel] RTSPServer disconnects client session in incomingRequestHandler1 [Update]

[Ralf Globisch]

Hi Ross,
I managed to track the cause of the disconnection down. 

It seems that the later connection's RR packets are not handled by RTPTransmissionStats::noteIncomingRR but by the RTSPServer::RTSPClientSession::incomingRequestHandler1.
Every RR fills the buffer up and when the buffer is finally full the RTSP server terminates the client connection.

Still don't know what exactly is causing the system to get into the error state.
Maybe this will give you some indication of what's going wrong since you know the system so in depth.

I am using the latest version of the liveMedia code: 2008/10/07
The problem occurs only when the server runs on a Linux Ubuntu system. I'm not sure if it will surface in other Linux distros.

To replicate do the following:

Setup:
  Client: OpenRtsp (sitting on another machine)
  Platform: Linux Ubuntu Hardy and Windows XP
  Transport: TCP

  Server: 
  live555 Dynamic RTSP Server (MediaServer)
  Platform: Linux Ubuntu Hardy
  Platform: Windows XP: Bug does NOT occur when the server is running on this platform

Steps:

1) Add some debug output to RTSPServer::RTSPClientSession::incomingRequestHandler1 to show that the handler was called. This must be before the 
"if (!endOfMsg) return;" statement. (once the system is in this erroneous state the method exits at this point)

2) Compile the liveMedia library with DEBUG_RR.

3) Run the server

4) Connect the first openRtsp client over tcp. At this point you'll see the RR debug output on the console. Let it run for about a minute or so. (The problem only seems to occur once the system has been running for a while: related to rtcp timeout maybe?)

5) Disconnect the openRtsp client.

6) Reconnect the client: if the RR output shows up on the server console, let the openRtsp client run for a couple of seconds.

7) Repeat 5 - 6 until after connection you see the RTSPServer::RTSPClientSession::incomingRequestHandler1 output instead of the RR output. 

At this point the RTSPClientSession handler is used for each RR packet and when the buffer is full, the connection is terminated.

In our system we obviously don't break the server following these steps. Our client connects only twice, once to sniff packets to obtain information about the media type and the second time to stream the media type.
This "double-connection" is enough for the server to go into this error state and disconnect our clients most of the time.

I've attached both the Windows and the Linux server output. Not sure if that helps track the bug down?

Any ideas?

Regards,
Ralf


-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Debug_Linux.txt
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081030/058b718e/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Debug_Windows.txt
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081030/058b718e/attachment-0003.txt>