cdh4u / draft-ice-pac Goto Github PK

If things are taking too long, it can try an ICE restart at any point.

The "alternative c)" that I proposed is to "Start the timer as soon as we have received a remote offer or answer and have also sent a local candidate to the remote side".

The rationale for this is:
A) we can't start ICE processing (checks) until we get a remote offer/answer with ICE credentials
B) we can't receive an incoming check that could create a prflx candidate unless we sent a candidate to the remote side

5. The current draft says "MUST wait for" and "N SHOULD be X". But together, that amounts to "SHOULD wait for X", so the whole
   RFC ends up being a big SHOULD. Is that normal for an RFC to only have SHOULDs and not MUSTs? Seems less meaningful because

This is a reasonable point. We could say that the implementation MUST wait for enough time to receive peer-reflexive candidates. This value SHOULD be the local connectivity check timeout.

TBH, I think it sort of invalidates end-of-candidates, since it's now clear that you can't start pruning upon receiving end-of-candidates. We might just want to never send it (and perhaps remove it in a future revision).

I agree we should use the "max duration of a connectivity check transaction".

I think this value will work just fine in real world scenarios. And if the timer expires before we have tested all pairs (this can certainly happen, in the case of two hosts with no connectivity to each other), we just resume existing ICE processing, and fail when everything moves to the failed state (i.e., every pair has timed out). The timer is simply there to prevent premature failures.

[from the list]
... I think this implies that one shouldn't be too hasty to declare ICE completion either.

Since some implementations may malfunction if they don't get a USE-CANDIDATE quickly, I am not sure if we can wait the full STUN timeout interval, but perhaps a somewhat shorter delay (e.g. a few seconds) could be recommended before sending USE-CANDIDATE.

Looking at this problem it is clear that it would be difficult to come up with a timer value which will work for all possible candidate lists. It probably makes sense to have some sort signaling message which requests ICE nomination time out extension. This signaling message will let the other ICE agent know that ICE agent is still sending binding requests and needs nomination time out extended. In other words, ICE should not fail for 32 seconds, but agent should send a signaling message (INFO with current candidates or something similar) every 16 seconds to keep negotiation going unless a binding request from remote was received. This signaling message would extend nomination timeout for another 32 sec from the time the message was received.