On 6 Mar 2012, at 13:24, Randell Jesup wrote:
On 3/6/2012 2:52 AM, Harald Alvestrand wrote:
On 03/06/2012 12:32 AM, Colin Perkins wrote:
Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution.
Colin
Great - people have been doing this forever, but totally ad-hoc (and for different reasons).
In the past I've seen (and used) values in the 10-30 second timeframe used to drop calls with lack of connectivity, though for VoIP 30 seconds is *forever*; few people will wait that long before abandoning a phone call (more might wait that long before abandoning an online 'call', at least today). Most uses I've seen relied on the recipient to end the call, not the sender to do so via RTCP, since most failures in mid-call are loss of connectivity in both directions.
A receiver-based circuit-breaker should be added too, I agree. Colin
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : RTP Congestion Control: Circuit Breakers for Unicast Sessions Author(s) : Colin Perkins Varun Singh Filename : draft-perkins-avtcore-rtp-circuit-breakers-00.txt Pages : 14 Date : 2012-03-05
A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breake...
Section 4.1:
Accordingly, if a sender of RTP data packets receives two or more consecutive RTCP RR packets from the same receiver that correspond to its transmission and have a non-increasing extended highest sequence number received field, then that sender SHOULD cease transmission.
If I see RTCP packets with
1: highest sequence number = 2 2: highest sequence number = 2 3: highest sequence number = 2
do I cease transmission after packet 3 has arrived, or after packet 2 has arrived?
As was later clarified, the answer was after packet 3.
It would be good to point to the RFC 3550 definition of "reporting interval"; perhaps even discuss how it's calculated, and re-emphasize that it's not 3 RTCP packets in the AVPF case.
-- Randell Jesup randell-ietf@jesup.org _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- Colin Perkins http://csperkins.org/