[Live-devel] RTSP client: handle connection header

Nathan nathan at team-mediaportal.com
Wed Jul 13 01:35:27 PDT 2016


Hello Ross
 
Using LIVE555 as a client to receive RTSP/RTP/MPEG2-TS streams from a 3rd party
RTSP server, I've encountered a problem which I'm hoping can be easily fixed.
 
Sequence for reproducing is as follows...
 
1. Use LIVE555 RTSP client to send a SETUP request:
 
SETUP rtsp://172.31.0.1:554/stream1760952/ RTSP/1.0
CSeq: 2
User-Agent: LIVE555 Streaming Media v2015.07.31
Transport: RTP/AVP;unicast;client_port=62392-62393

2. The 3rd party server responsds:
 
RTSP/1.0 200 OK
CSeq: 2
Session: 3621155123
Blocksize: 15452
Transport: RTP/AVP;unicast;client_port=62392-62393;server_port=5001-5002
Server: DOTS 2.0 UPnP/1.0 ATI TV Wonder OpenCable Receiver (37F0), Unit
#1/(null)
CONNECTION: Close
CACHE-CONTROL: no-cache

So far so good.
 
3. Attempt to use LIVE555 RTSP client to send a PLAY request:
 
PLAY rtsp://172.31.0.1:554/stream1760952/ RTSP/1.0
CSeq: 3
User-Agent: LIVE555 Streaming Media v2015.07.31
Session: 3621155123
Range: npt=0.000-

 
==> LIVE555 returns error code -10057 (-WSAENOTCONN).
 
 
After some investigation I think I've discovered the cause of the problem.
 
The connection header in the SETUP response indicates that the server expects
LIVE555 to close its socket on reception of that response. However LIVE555
currently does not handle the connection header, and therefore doesn't close its
socket. When asked to send the PLAY request, LIVE555 almost always attempts to
reuse the same [closed] socket. Since the server has closed its end of the
socket, the PLAY request fails. Occasionally when LIVE555 coincidentally sends
the PLAY request on a newly connected socket, the request succeeds and the RTP
stream can connect.
 
The following patch seems to be an effective solution:
(RTSPClient.cpp line 1745)
    } else if (checkForHeader(lineStart, "Connection:", 11, headerParamsStr)) {
      if (_strncasecmp(headerParamsStr, "Close", 5) == 0) {
        resetTCPSockets();
      }
    }
 
 
If you consider this solution to be appropriate, please would you consider
accepting this patch.
 
Thanks and regards,
Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20160713/6a51ed5e/attachment.html>


More information about the live-devel mailing list