[Live-devel] RTP-over-TCP streaming (Noam Camiel)

[Ron McOuat]

I have observed a similar sounding situation as follows:

Use openRTSP to receive the video stream from an Axis camera, I have tried several models

Using RTP over UDP (no -t or -T option) will run for hours
Using RTP over TCP (-t option) will fail somewhere between 600 and 2000 seconds
Using HTTP tunneling (-T 80 option) will run for hours

Compiling the live555 code with debug on reveals the end sequence looks like this:

~~~~~~~~~~~~~~~ Debug trace ~~~~~~~~~~~~~~~
sendRTPOverTCP: 976 bytes over channel 0 (socket 8)
sendRTPOverTCP: completed
SocketDescriptor::tcpReadHandler() reading 16 bytes on channel 20
SocketDescriptor::tcpReadHandler() reading 16 bytes on channel 21
[0x300be0]saw incoming RTCP packet (from address 136.244.255.191, port 1280)
 80c90001 6fc0e531 81cb0001 6fc0e531
RR
validated RTCP subpacket (type 2): 0, 201, 0, 0x6fc0e531
BYE
Received RTCP "BYE" on "video/MP4V-ES" subsession (after 672 seconds)
Sending request: TEARDOWN rtsp://69.67.172.61:554/mpeg4/1/media.amp/ RTSP/1.0
CSeq: 8
Session: 2014422318
User-Agent: ./testProgs/openRTSP (LIVE555 Streaming Media v2007.08.03)


RTCPInstance[0x300be0]::~RTCPInstance()
sending BYE
sending RTCP packet
 81c90007 af22ce4c 6fc0e531 00000000 00023418 00000388 bfcf8f2c 000127e1 81cb0001 af22ce4c
sendRTPOverTCP: 40 bytes over channel 21 (socket 3)
sendRTPOverTCP: completed
~~~~~~~~~~~~ End of trace ~~~~~~~~~~~~~~~~

What appears to happen that is different when the stream ends is the 2 lines from

SocketDescriptor::tcpReadHandler() gets a 16 byte read on channel 20 then another 16 bytes on channel 21. Often there is a REPORT just before this but not always.

The end of stream does not go through any timeouts, the debug output just rolls up and stops when I have observed this in real time.

Also the address and port numbers reported for the source for both -t and -T port reported in the trace are not valid but with UDP they are good. The correct source IP address is in the TEARDOWN message.

I have not had a chance to dig into why this is happening yet because I have some other pressing issues to work on and have worked around this for my own purposes. However, seeing this on the mailing list prompted me to send in my observations.

The system running the live555 code is OSX 10.4.10 with all patches. I was also going to verify on Linux in case this is a problem with the system interface to select().

Ron McOuat




Message: 3
Date: Tue, 2 Oct 2007 17:10:25 -0700 (PDT)
From: Noam Camiel <noamatari at yahoo.com>
Subject: [Live-devel] RTP-over-TCP streaming
To: LIVE555 Streaming Media - development & use
	<live-devel at ns.live555.com>
Message-ID: <76628.29785.qm at web53302.mail.re2.yahoo.com>
Content-Type: text/plain; charset=us-ascii

Hello

I have a problem when accessing live server's stream  using RTP-over-TCP as opposed to UDP.

I have used the testOnDemandRTSPServer example to play a stream of of mpeg4 encodered frames (elementary stream) and was successful with both VLC and Quicktime as well as RealPlayer, using unicast UDP.

But when I try to connect to the server via TCP (RTP over TCP), the video is played for a short time and then stops (with a reports - due to a network problem).  This short time duration can be anywhere between 30 seconds and 10 minutes.

Which is the right way to stream RTP over TCP? Should I use a different example from live than testOnDemandRTSPServer?

Thanks,
Noam Camiel