[Live-devel] [PATCH] Declare RTSP server's timeout

[Warren Young]

Ross Finlayson wrote:
>>
>> I have a client here that doesn't send RTCP RR packets to the server.
> 
> Your client is broken, because RTCP is a required part of the RTP/RTCP 
> standard.  It is not optional functionality.

RFC 3550, section 6.0: "[RTCP] SHOULD be used in all environments, but 
particularly in the IP multicast environment."

I'm sure I don't need to tell you that "SHOULD" is standardese for 
"optional".  Plus, I'm doing unicast on relatively small private LANs. 
RTCP RR solves problems that largely don't exist in my world.

Later, in section 6.2: "Turning off RTCP reception reports is NOT 
RECOMMENDED...  However, doing so may be appropriate for systems... that 
don't require feedback on the quality of reception or liveness of 
receivers and that have other means to avoid congestion."

That definitely applies to my situation.  My world is K-12 schools, 
where managed switches are considered high technology, capable of doing 
anything such a small LAN needs.  That's how you get QoS and congestion 
control (VLANs) in my world.  That just leaves alternate ways to 
indicate liveness, which is the subject of this patch.

> I might end up changing 
> the default "reclamationTestSeconds" value from 45 to 60

You might go slightly higher, to account for differences in 
interpretation of time between client and server.  Not just clock drift 
and such, but also, how do you define time t=0?  Is it the transmission 
time of the first RTSP request, or from the time of receiving the first 
RTP packet from the server, or somewhere between?  There's usually a 
couple of seconds difference between these two times.  The first 
keepalive could come in 62 seconds past the server's t=0.  Every one 
thereafter will be ~60 seconds apart.

> I won't be adding your patch to add the 
> "timeout=" parameter, because that would be misleading.

What if the server decided to do this based on the User-Agent value?  I 
can make it check for my client, and send it only when it sees that it's 
necessary.

Understand the tradeoff: we'd be adding this code to save 0.00004 Mbit/s 
of network bandwidth.  (~300 bytes every 60 seconds.)