[FEATURE] Consistence of TCP/TLS connections and usrloc data

[vasilevalex]

Is your feature request related to a problem? Please describe.

Now if TCP/TLS connection is lost, contact is still in usrloc database. And we have to wait until expiration (long time) or use OPTIONS ping (rudiment from UDP). And vice versa, if for some reason contact was deleted from usrloc database (e.g. issue #1580 ), TCP/TLS connection still can be alive and phone has no errors, as it is still in REGISTERED state, but all the calls to the phone are dropped by proxy.

Describe the solution you'd like
So it would be nice to destroy TCP/TLS connection if related contact is deleted from usrloc. And delete contact if its' connection was destroyed. So usrloc database will be consistent with alive TCP/TLS connections.

Implementation

• Component: core, usrloc module

Additional context
Of course there can be TCP/TLS connections which has no usrloc contacts - they just should not have this relation and processed as currently.

[bogdan-iancu]

@vasilevalex , in SIP there is strong relation between the transport connections and the actual SIP sessions. For example a TCP connection can be used for a registration session, but also for subscription sessions, even for calling sessions - same TCP conns. Also a call may start via TCP conn and terminate via different TCP conn (re-opened).
So closing the TCP conn if the registration is dead may be dangerous as you can kill other SIP sessions sharing that TCP conn.

[vasilevalex]

Hi @bogdan-iancu

in SIP there is strong relation between the transport connections and the actual SIP sessions.

Yes, sure.

So closing the TCP conn if the registration is dead may be dangerous as you can kill other SIP sessions sharing that TCP conn.

I'm partially agree. Yes, of course killing is always dangerous. If we kill session, client device immediately reestablish it (if it is buggy and doesn't do it - there is big problem).
On the other hand, if registration is deleted, but TCP session still alive, we have worse situation. Client device 1) still thinks that it is successfully registered, 2) it can call, so everything looks ok. But it can't receive calls (and other messages), as OpenSIPS doesn't know how to contact it. As phones usually have 1 hour expiration for registration, I'd prefer to drop session and allow client device to re-establish it and renew registration. May be somebody prefer to keep the connection.
It could be boolean parameter in usrloc to choose the behavior.
Or even events for TCP sessions would be fine. You've discussed them in #1569

[vitalikvoip]

Accidentally found this feature-request. I've implemented a part of it some time ago. When a proxy loses a TCP/TLS/WS/WSS connection it generates an event with ip:port of the remote peer. When opensips accepts REGISTER it generates the corresponding event and I save ip:port and contact info to a local cache. Then in TCP disconnect event_route I just fetch a contact from local cache and call remove() function.

[bogdan-iancu]

We could consider a new save() flag to indicate if the contact should be automatically removed upon transport layer disconnect.

[vitalikvoip]

I thought about an additional flag but wanted to give more control to a script writer like other actions when transport disconnects.
Just need to be careful with a corner case when the same endpoint (ip:port) is used by a PBX to register multiple sip accounts.

[bogdan-iancu]

If someone what's more control (and he knows what he's doing), he can use the events + cache + other ingredients to script his stuff, without using the flag. The flag is to provide a fast solution (no additional scripting) and a simple solution (you do not have to be a script master to make it work).

In regards to the mentioned corner cases, I disagree - the trigger is the TCP connection layer, and if the conn goes down, all the contacts registered via that conn will be removed. Which is ok even if you have a PBX registering all its accounts via the same conn

[vitalikvoip]

The described corner case makes sense if one wants to use cache for mapping and then unregister from config. save() flag is not affected. BTW, I can prepare a patch for TCP/TLS/WS/WSS connections events (accepted, terminated) if it makes sense to include it into the public version.

[bogdan-iancu]

sure @vitalikvoip , patches are welcome :)

[petekelly]

@bogdan-iancu this would be useful for a number of cases I've come across too :)

[nathanleyton]

@bogdan-iancu this would be useful for a number of cases I've come across too :)

I think we are one of your cases 👍

[vladpaiu]

A 'manual' solution is possible by using the below event in OpenSIPS 3.3

https://www.opensips.org/Documentation/Interface-CoreEvents-3-3#toc5

along with

https://opensips.org/html/docs/modules/3.3.x/registrar.html#func_remove_ip_port

[vitalikvoip]

Hi there Back in 2018 I've added E_TCP_CLOSE and E_TLS_CLOSE events in order to call remove(). Contact info and corresponding src_ip:src_port pairs were saved in a local cache from E_UL_CONTACT_INSERT & E_UL_CONTACT_UPDATE handlers. Those patches were done to 2.4 branch which is pretty old. Looks like modern E_CORE_TCP_DISCONNECT does the same and my patched are obsolete.

…

A 'manual' solution is possible by using the below event in OpenSIPS 3.3 https://www.opensips.org/Documentation/Interface-CoreEvents-3-3#toc5 along with https://opensips.org/html/docs/modules/3.3.x/registrar.html#func_remove_ip_port — Reply to this email directly, view it on GitHub <#1769 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3PPGPMNGAWDDLVPN5IXZDVD3U5VANCNFSM4IDVFAGA>. You are receiving this because you were mentioned.Message ID: ***@***.***>