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/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
