[R-C] Receiver-based circuit breakers (Re: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt)

[Randell Jesup]

On 3/7/2012 5:30 AM, Harald Alvestrand wrote:
> Branching the subject line....
>
> On 03/06/2012 11:24 PM, Colin Perkins wrote:
>> On 6 Mar 2012, at 13:24, Randell Jesup wrote:
>>> 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.
> This may be more application dependent, since a receiver that can't get
> packets through to the sender is not going to be able to stop the flow.

Often it can end the call via signaling however even if p2p connectivity 
is lost.

Also, this assumes that the loss is not something that ICE is able to 
renegotiate around (IP change, router reset, etc) - if the loss isn't 
total, ICE *should* be able to re-establish communication, even if only 
via a TURN server.

It does imply that on apparent connectivity loss we should restart ICE 
(IP change we should notice, but router reset we might not).  Also, ICE 
probes probably shouldn't wait until things are at a critical stage (3rd 
RTCP interval with no reception).

a) total connectivity loss
    Sender and receiver must time out on lack of media and/or RTCP
b) one-way loss sender->receiver
    Sender can use circuit breaker
    Receiver must time out on lack of media and/or RTCP
c) one-way loss receiver->sender
    Mirror of b

When one side decides to give up, it must attempt to signal this to the 
other side both via RTCP BYE's and by ending the call via signaling if 
possible.

> It can take various measures to get the message through to the sender
> that bad things are happening (RTCP, signalling), but these may be
> dependent on *something* working.

Right.  Though restarting ICE may make something work (but typically 
signaling will remain up, though if the loss is near-total in the 
internet->receiver direction, the receiver may have trouble completing a 
"end the call" transaction to the server, even if their packets are 
getting out.  The receiver must end the call and stop sending regardless 
of ability to tell the sender to stop sending.

-- 
Randell Jesup
randell-ietf at jesup.org