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

[Christer Holmberg <[e-mail]>]

Hi,

The main purpose of ICE consent freshness is not to detect crashed endpoints. For that ICE keepalives are enough.

Regards,

Christer

From: Wish <[e-mail]> On Behalf Of Sergio Garcia Murillo
Sent: perjantai 10. syyskuuta 2021 23.53
To: Nils Ohlmeier <[e-mail]>
Cc: WISH List <[e-mail]>rg>; Juliusz Chroboczek <[e-mail]>
Subject: Re: [Wish] How to detect a crashed client?


El vie., 10 sept. 2021 22:42, Nils Ohlmeier <[e-mail]<mailto:[e-mail]>> escribió:

On Sep 9, 2021, at 13:10, Sergio Garcia Murillo <[e-mail]<mailto:[e-mail]>> wrote:
El jue, 9 sept 2021 a las 19:52, Nils Ohlmeier (<[e-mail]<mailto:[e-mail]>>) escribió:
[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.

Good point. Although I want to highlight for folks not that familiar with ICE specs that technically nothing forbids an implementer from claiming his server is an ice-lite implementation, but then to send out consent requests once the connection is established. I would argue that this still makes your implementation considerably easier compared to a full ICE stack.

that's exactly what I have implemented in my media server, I call it ICE lite+ 🤣




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.

I fully agree on the 30s here.
So maybe the easiest is then to let the client side decide when to give up with ICE consent. And it needs to be prepared to handle a 404 on it’s ICE restart request, to then do a full restart of the connection.

Completely agree.

Best regards
Sergio