[FFmpeg-devel] [PATCH] Don't send keepalive messages when interleaving RTP over TCP

[Ori Pessach]

It should do 2. If you're looking for justification in the RFC, it's
because a server must send a response to OPTIONS requests, and an OPTIONS
request shouldn't cause a server to stop streaming.

Under normal circumstances, this shouldn't be a problem for the client or
for the server. Why do you think it is?

One way to think about it is that your server's network interface
serializes all traffic, anyway. Just because you're able to send data on
two sockets (one UDP and one TCP sockets) "simultaneously", doesn't mean
that the data transmission is actually concurrent. When you realize that,
that stall you're worried about doesn't seem that bad anymore. In fact,
there is no stall. A far bigger problem for interleaved transmission in
RTSP is the buffering that happens with TCP traffic, which can cause a
delay, relative to what you'd experience with a UDP transport.



On Thu, Apr 24, 2014 at 12:53 PM, Fred Rothganger <frothga at sandia.gov>wrote:

> On 04/24/2014 12:13 PM, Ori Pessach wrote:
>
>> Many RTSP servers will time out a session if they don't receive a
>> keepalive
>> message in a timely manner, regardless of the transport used. This patch
>> might cause these servers to stop sending data when they determine that
>> the
>> client has timed out.
>>
>> Specifically, many IP cameras behave in this way. I'm pretty sure the
>> behavior is mandated by rfc 2326.
>>
>>
> What is the correct behavior for a server?
>
> FFmpeg (rtspdec.c) sends an OPTIONS request every 30 seconds. When the
> server receives this on the incoming side of the TCP connection, what
> should it do?
> 1) Send no response to the OPTIONS request. Make a note that keepalive has
> been sent and remain in the Playing state. Continue sending RTP and RTCP
> packets.
> 2) Stall the RTP and RTCP streams. Send the OPTIONS response message.
> Immediately resume the streams.
> 3) Stall, respond, and do not resume streaming.
>
> I failed to find anything in the RFC that clearly spells out how to handle
> this aspect of interleaving. If you could point me to the passage, it would
> be most appreciated!
>
> -- Fred
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>