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

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

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

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