
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@jesup.org