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

[Sergio Garcia Murillo <[e-mail]>]

El jue, 9 sept 2021 a las 19:52, Nils Ohlmeier (<[e-mail]>)
escribió:

> > 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.
>

That's true in case of full ice servers, but servers may be ice lite which
shouldn't send ice requests.


>
> 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.
>

I am not sure if we should mandate it in the spec, setting a timeout grace
period once the ice timer has expired could be implementation specific. The
client has no way of knowing the exact timeout on the server side, so it
would have the same effect to raise the timeout server side, or have a
grace period deleting the session server side.

Also, in case of ice restart the behaviour would be the same, the whip
client would have to try an ice restart, and if the session is not found,
do a full restart (based reconnection policies on client side).

IMHO, doing an ice restart after 30s or 40s of disconnection does not offer
any benefit over full restart, but others may not think alike.

Best regards
Sergio