[Live-devel] Using RTP/RTCP over TCP, sendDataOverTCP retry

[Erik Oomen]

> Op 17 jul. 2015, om 10:15 heeft Ross Finlayson <finlayson at live555.com> het volgende geschreven:
> 
> 
>> On Jul 15, 2015, at 9:13 PM, Erik Oomen <erik.oomen at zepcam.com> wrote:
>> 
>> I’m using live555 to stream H264+PCMU audio between two servers (both are bare Linux 64bit under my control).  Due to firewall reasons I have chosen to use TCP. The sending server has 100Mbit FD, the receiver has 20Mbit FD bandwidth, 8 hops between them and average 9msec RTT.
>> 
>> For some reason the sender will stop sending because the sendDataOverTCP is seeing EAGAIN on a regular basis (every minute more or less).  Perhaps due to congestion, a saturated line or something like that
> 
> Yes, you are exceeding the capacity of your network - likely because of the firewall(s) that are inbetween the server and client.  (Note, BTW, that the "capacity of your network” - especially for TCP connections - usually has little to do with the nominal bitrate of the network interfaces at each end.)
Ok, clear.  I also understand that tcp is not suited for hard realtime communications, however sometimes I have to fallback to TCP.

> 
>> My question:  What is the reason to not use ‘forceSendToSucceed’ for the framingHeader in sendRTPorRTCPPacketOverTCP?
> 
> Because this would cause the server to block for an unpredictable (and possibly significant) length of time, which would prevent the server from being able to doing anything else (like serving stream to other client(s)) in the meantime.  That’s why we do blocking packet sends only when we really need to - i.e., after we’ve already successfully written the framing header.

Ok thats clever.  However, once the framing header hits a failure, the socket is not used anymore (see below) and it is now up to the client to detect a timeout (VLC for example just waits for 10 seconds before stopping because there is no more incoming data).  testRTSPClient just stops receiving.
Perhaps not only de-registering but also closing the socket would be a better shutdown?  

> 
> 
>>  Because, this is causing my stream to stop.
> 
> No, it’s not causing your stream to ‘stop’.  It’s possibly causing some of your RTP datagrams to not get transmitted - which is reasonable and appropriate when your network is congested.  (Note that you’re still streaming datagrams, even though you’re framing them over a TCP connection.)

I don’t think so because this condition is triggered if sending the framing data hits an error and the socket is removed for further usage (not closed however).

    } else if (sendResult < 0) {
      // Because the "send()" call failed, assume that the socket is now unusable, so stop
      // using it (for both RTP and RTCP):
      removeStreamSocket(socketNum, 0xFF);
}

This behaviour can be seen with the testRTSPClient.  The connection is active however the RTP datagrams are not transmitted anymore due the the ‘removeStreamSocket’.

> 
>> 
>> Changing the forceSendToSucceed in first  sendDataOverTCP in RTPInterface::sendRTPorRTCPPacketOverTCP fixes my problem
> 
> No, it doesn’t (unless you’re planning on only ever streaming one stream at a time from this server, and possibly not even then).  In any case, if you modify the supplied code, you can expect no support on this mailing list.

In my case I’m receiving video over 3G mobile connection with ‘huge’ variable latencies.  This video is retrieved on a server which re-restreams this data over RTSP to another server. The few delays when using RTP over TCP are of no concern. 

I completely understand.  The modifications are just to understand the behavior.

Erik Oomen.