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

Ross Finlayson finlayson at live555.com
Thu Aug 21 11:47:10 PDT 2008


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

I don't understand/believe this.  Most people, when they try to 
explain why they don't implement RTCP, give all sorts of excuses, but 
deep down, the reason they don't implement RTCP is because they think 
it's too 'complicated'.  But if you're using our software to develop 
your client, then there's no complexity - you already get a RTCP 
implementation that you enable with just one line of code.  Anyway, 
your client already needs to *receive* RTCP "SR" packets, in order to 
do A/V sync, unless you are sending audio-only, video-only, or a 
Transport Stream only.

Also, if your client doesn't send RTCP "RR" packets, then you will 
miss out on enhanced server features - such as QOS statistics - that 
we may implement in the future.


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

OK, I might make it 65 seconds, by default.  But there are no current 
plans to have our server send the "timeout=" parameter, for the 
reasons I've given.
-- 

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


More information about the live-devel mailing list