Reproduce connecting
Scenario
- Call device A (network 0)
- A decline call
- A change to network 1
- Call device A (network 1) after ~30secs tcp closed + call OK
- NOTE: network 1 must be accessible only via TURN, it's important (A<->TURN<->B)
- A decline call
- A change to network 0
- Call device A
Expected result
On TCP timeout the call should come
Current result
Stay connecting...
Observation
- Coturn doesn't seems to detect half open connections. In fact, the bug here is that our keep alive are sent every 30 secs, but... A->TURN is opened ; TURN->B is closed. And the keep alive / packets will be ok during 5 minutes (the allocation time) before TURN to actually drop the connection
Activity
added connectivity ~21 + 1 deleted label
I agree that proper handling of the timeounts is important, e.g. to prevent problems with some edge cases or bug spilling effects.
Though, for continuous conections, shouldn't the client watch or register for local network status changes and renew the connection as soon as the device connects to a(nother) network?
Edited by Ring ThingGood, I'm not that familar with it, about the TURN server problem I basically just add some external questions here (can sometimes spark ideas).
Maybe the problem qualifies as a coturn bug?
Workarounds? Could the client A reset/close some turn session upon network change? Or always close/renew turn session before calling?
NB: From the description, I'm not exactly sure what steps B does.
Maybe the problem qualifies as a coturn bug?
No, they only implement TURN RFCs and they should not add any keep alive as it's not a problem to have half open connections for the TURN (as it is its role).
Could the client A reset/close some turn session upon network change?
This can't work. That's the whole thing of the keep alive. sporadic network changes can occurs. The call MUST NOT be cut if it can continues. So if you have an internet shutdown, local calls must continues while calls will be cut via keep alive or broken pipe errors. Opening and negotiating sockets take time, so if it can be avoided it should
A good resources about how TCP works https://blog.cloudflare.com/when-tcp-sockets-refuse-to-die/
The only good solution I can see for now is to allocate permissions for 30 secs instead of 5 min right now.
I'm not sure what is meant by permissions for 30secs.
The call MUST NOT be cut if it can continues.
I assumed switching network (and IP) makes it impossible to ever continue/reusing a TCP connection. And thus when the network interface changes, it would be most logical for the client that can notice that, to initiate to reset/re-establish all connections immediately. (Setting them up again right-away should always be faster than first waiting for a timeout of the stale connection.)
Of course, waiting for the timeouts is needed when there is a network congestion or interruption in the network between the clients, or clients<->proxy, when the clients don't see an IP change in their local network links. That allows to detect temporary interruptions and have a threshold before trying to re-establish.
Edited by Ring ThingThe call MUST NOT be cut if it can continues.
Hm, I understood the description as talking about establishing calls (after declining/switching lan/wifi). For that, I guessed that re-establishing would also not delay more then having to wait for a timeout, if a connection has become stale.
Edited by Ring Thing-
I assumed switching network (and IP) makes it impossible to ever continue/reusing a TCP connection.
This can be false in a lot of cases. I can have a call in my company, enable a VPN the connection will stay alive cause the company's network is still accessible. On mobile, some android version keeps socket from previous network opened and usable. So I can start a call in 4g, move to wifi and have usable calls. The only way to detect that a socket is usable is to use it.
I think for those operating system versions that have made sockets persist over network and IP changes, it would then be an operating system issue.
Then the OS has to immediately probe the connections after an IP change (e.g. re-start keep-alive timer with short retry interval and timeout) to properly maintain or close the connection.
On all other platforms, I think it would still remain the applications' duty to register or watch for IP changes to quickly re-establish connections.
Edited by Ring Thing-
On all other platforms, I think it would still remain the applications' duty to register or watch for IP changes to quickly re-establish connections.
Again Jami already got signals for connectivityChange() to update ips (in ICE candidates and such)
Anyway note for this issue:
Solution will be implemented by https://review.jami.net/c/ring-daemon/+/17904
As keep alive will not break with TURN connections, the previous timeout for fallbacking on "Connecting" is re-done. (removed by https://git.jami.net/savoirfairelinux/ring-daemon/-/commit/dbcb0e6d1ecc2526b10d9f7e8b2b8a64b5da8d25 where after 3 secs without answer, a new socket is re-negotiated).
Now, in 17904, each connectivityChange() or each call will send a ping/pong on the multiplexed socket. If no response, the connection will be cut and call will be renegotiated.
TODO: connectivityChanged() ; do it if peer got daemon > 10.0.0
added SprintIn progress label
removed SprintIn progress label
added SprintTo review label
mentioned in commit ffa12c74
added SprintDone label and removed SprintTo review label
removed SprintDone label
added severityhigh label
