[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