[libnice] keepalive connchecks for TCP candidates

[Harald Glanzer]

thank you guys for your effort!
test-wise, i already enabled TCP binding requests for all candidates by commenting-out the code in question
which works just as expected - therefore, the binding requests must be forwarded by the TURN server.

therefore, i get a signal if the remote client dies away, no matter what candidate is used.

thx!
hari
________________________________________
Von: snifikino at gmail.com [snifikino at gmail.com]" im Auftrag von "Youness Alaoui [kakaroto at kakaroto.homelinux.net]
Gesendet: Dienstag, 23. Januar 2018 17:54
An: Olivier Crête
Cc: Harald Glanzer; nice at lists.freedesktop.org
Betreff: Re: [libnice] keepalive connchecks for TCP candidates

Humm... good question. the binding requests should always be sent I
think, I see in conncheck.c ~1337 (not ~850 as originally suggested),
the keepalives are disabled for non UDP local connections, but yes, in
the case of a TCP TURN proxy, that would be an issue.
I think that disabling keepalive for TCP would only work if the TURN
server itself had its own mechanism for keeping alive the connection
with the peers, but I don't think that's the case, so that code is
wrong.
The code comes from commit 714c9603ac3cc56c4e4da1c09949dc6fd8316ea2
which is mine and is from April 2014, and I have no idea why I pushed
that. Looking at the log, it came with the addition of tcp candidates
and all the native TCP candidate work, so I think the code should
really have been on whether the candidate is TCP candidate, not on
whether it's a UDP candidate connected to via a TCP proxy.
It makes sense to skip keepalives for TCP pairs (though not sure if
it's compliant), but in this use case, it's a bug that needs fixing.

Olivier: note that sending the keepalive would make the proxy forward
it, so it does help with the second-leg of the connection.

Hopefully that helps,
Youness.

On Tue, Jan 23, 2018 at 5:25 PM, Olivier Crête
<olivier.crete at collabora.com> wrote:
> Hi,
>
> If you use TCP candidates and the connection to the remote endpoint
> dies, I think the TCP connection to the turn server should get closed
> too. On the first leg, you can enable TCP keepalives. But it indeed
> doesn't help with the second leg.
>
> I'm not sure why we disabled the binding requests if TCP candidates are
> utilized. I believe in standard compliant mode (ie, not MSN), it should
> be fine.
>
> Maybe Youness has another idea,
>
> Olivier
>
>
> On Mon, 2018-01-22 at 16:13 +0000, Harald Glanzer wrote:
>> hi,
>>
>> for my appliation (farstream + libnice) i need some way to detect
>> network failures, i.e. i need
>> a way to get signalled whenever the _remote_ side disappears.
>>
>> it turned out that using binding requests as keepalive mechnism works
>> fine for UDP candidates. whenever the remote
>> side has network issues and disappears, the local side does some
>> retries and sends a signal which i am using to close the
>> session from the application side.
>>
>> nevertheless, if TURN with TCP candidates is utilized, no binding
>> requests are created (agent/conncheck.c, line ~850),
>> and therefore, i do not get notified that the transport channel is
>> not active any more. i guess this happens because the local
>> connection to
>> the TURN server itself is still active, but the _remote_ endpoint has
>> gone away (which, it seems, is not recognized by the TURN
>> server, who does not close the connection to the local TURN client).
>>
>> i am now struggling with the question if it makes sense to use
>> keepalive binding requests as connection-checks for TCP too?
>> i wonder if the TURN LIFETIME attribute ( https://tools.ietf.org/html
>> /rfc5766#section-14.2 ) would be suitable, and if libnice is able
>> to use this feature (some basic tests regarding LIFETIME were not
>> sucessfull..)
>>
>> thx in advance
>> hari
>> _______________________________________________
>> nice mailing list
>> nice at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/nice
> --
> Olivier Crête
> olivier.crete at collabora.com
> _______________________________________________
> nice mailing list
> nice at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nice