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

[Ross Finlayson]

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


> 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.


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

> 
> 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.

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/20150717/985d02c2/attachment.html>