Re: [Wish] How to detect a crashed client?

[Nils Ohlmeier <[e-mail]>]

> On Sep 9, 2021, at 09:10, Juliusz Chroboczek <[e-mail]> wrote:
> 
>> Which means that the server has to monitor the ICE requests and timeout
>> any client which hasn't issued a new ICE request to renovate the consent
>> in 30s.
> 
> So we're assuming that the client has a shorter ICE timeout than the
> server, right?  Otherwise the client won't get a chance to send an ICE
> restart.

[With my individual contributor hat on]

I think Sergios description above is actually not fully correct.

With ICE consent the client and the server both run their own independent ICE consent checks.
So the client sends consent requests and server answers them. And the server sends consent requests which the client has to answer.
If the client crashes, the servers consent checks will get no responses and then after 30 seconds can delete the PeerConnection.

But yes if the server then would delete the PeerConnection right after consent timed out I assume it would make it hard to execute an ICE restart if the client requests that N seconds later. This is different from the browser case, where the ICE consent timeout only changes the ICE connection state, but does not directly affect the lifetime of the PeerConnection itself.

I would suggest that instead of messing with the timers for ICE consent on the two different sides of the connection - BTW for browser endpoints the JS client can’t change the ICE consent timeout value - the spec should mandate that server endpoints need to keep the PeerConnection around for another N seconds after ICE consent timed out.

Best
  Nils Ohlmeier