[Live-devel] patch: Set forceSendToSucceed for RTP over TCP framingHeader

[Ross Finlayson]

No, you’re misunderstanding the purpose of this software.  It is intended for real-time streaming of media data - i.e., transmitting the media at its natural  rate, regardless of the capacity of the underlying network.  It uses RTP (which stands for “Real-time Transport Protocol”) - a datagram-based protocol.  This means that data packets can get lost, and necessarily *will* get lost if the media’s natural data rate exceeds the capacity of the network.

If, however, you want to transfer media with guaranteed no data loss - regardless of the capacity of the underlying network - then you should use some other protocol, e.g., HTTP (which runs over TCP or QUIC - protocols that guarantee reliable data delivery).

While it is true that the RTSP protocol contains a mechanism for the optional encapsulation of RTP media packets inside the RTSP (TCP) control stream, this is something that should be used *only if* you know that you have a firewall - between the sender and receiver - that blocks UDP packets.  Otherwise, you should use the (much more efficient) regular RTP-over-UDP.

In particular:

> As currently implemented, should send() of the 4-byte framingHeader return -EAGAIN, a gap in RTP sequence occurs, with dropped media data.

Yes, this is exactly as intended (see above).  It will not be changed.


> I assume the implementation as-is was designed to prioritize realtimeness over completeness.

The software doesn’t ‘prioritize’ realtimeness; it *delivers* realtimeness.  It’s not intended to guarantee ‘completeness’ at all.
 

> More concerningly, I've observed that -EAGAIN errno is returned when sending the header, even though there appears to be adequate transmit capacity -- iproute2/ss shows an empty or near empty send-q

If you are exceeding the capacity of your network, then this doesn’t necessarily manifest itself as a full queue at the sender end.  The congestion might be occurring downstream on the network (or perhaps at the receiver)


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/