rtsp: Make RTSP TIMEOUT in RTP/RTSP/TCP transport deterministic

Submitted by Dag Gullberg

Link to original bug (#770934)

Description

When streaming over RTP/RTSP/TCP, and loosing network connection, there is a RTSP TIMEOUT triggered to run.

When there is congestion or otherwise some problem with the network, a watch BACKLOG is used to store messages intended for send. In the case of a disconnect, the queue will fill up, but it take a few moments (queue size set to e.g. 100).

The issue is that during the use of the BACKLOG queue, the keep-alive is still handled, although there are no connection. This means that the RTSP TIMEOUT (60+5s) is touched and reset at the keep-alive and not allowed to run until after up to several seconds have passed, and the queue is full.

It would be natural that the RTSP TIMEOUT is allowed to run at the first possible moment there is an indication of LOSS, like the RESOURCE TEMPORARILY UNAVAILABLE indication from the non-blocking write socket when it receives EWOULDBLOCK in the function write_bytes().

The impact is that functionality depending on deterministic values of the time delay between the last frame of the lost stream and the timeout expiration, will have a hard time bridging that gap. (e.g. fail over file save locally)

This manifest itself only in TCP not in UDP.

A patch has been prepared that addresses this issue.