Hi,
I want to propose a patch to usrloc:
https://github.com/kamailio/kamailio/commit/14852a98ed46b7a88c92bff31c319d26...
this patch adds a new parameter, close_expired_tcp, that makes usrloc request the main TCP process to end the connections of expired registrations (assuming 1 connection = 1 contact).
It enables to release resources on the system ASAP, in the event of a lost connection (e.g. when clients are on mobile networks).
Any thoughts?
Cheers,
On 25 Feb 2015, at 19:05, Camille Oudot camille.oudot@orange.com wrote:
As you indicate, if the registrar is behind an outbound server, we should not close. This is indicated by a path header normally.
If there's no path, I wonder if there is any reason not to make this a default behaviour? Why keep the connection?
/O
Le Thu, 26 Feb 2015 07:57:49 +0100, "Olle E. Johansson" oej@edvina.net a écrit :
If there's no path, I wonder if there is any reason not to make this a default behaviour? Why keep the connection?
If a SIP user agent has several contacts registered through the same connection (I think it is possible although I've not encountered this case yet), then we don't expect the connection to be closed on the first expired contact, so I'm not sure about making this a default behavior.
On 26/02/15 11:11, Camille Oudot wrote:
Having it optional is good in the first place, perhaps the new parameter can be extended in the future to get new values that will make the behaviour different (e.g., close when there is no path).
Can you also check the report from the email: - http://lists.sip-router.org/pipermail/sr-users/2015-February/087105.html
It appears to be a side effect of the last commits related to tcpops module.
Cheers, Daniel
Le Thu, 26 Feb 2015 11:18:39 +0100, Daniel-Constantin Mierla miconda@gmail.com a écrit :
Hi,
i've modified the patch to handle the several usrloc database modes, and rebased it in a new branch:
https://github.com/kamailio/kamailio/commit/42dc7c8d17612b9d7a2dfa68bc9eb472...
I plan to merge it into master if it's fine with you.
Cheers,
Hi,
I have a feeling that this patch creates a big opportunity for closing wrong connections. Lets imagine the situation when you have a contact with the tcpconn_id=X and this contact wasn't refreshed by a UA in time. When proposed option is enabled kamailio will close a connection with ID = X at the next timer run. But we have no guarantee that ID = X is still identifies connection we want to close because this connection could be closed before timer run and then its ID reused by another client.
Le Mon, 23 Mar 2015 17:31:33 +0200, Vitaliy Aleksandrov vitalik.voip@gmail.com a écrit :
The way the id is attributed make it unique by kamailio instance. The id is just a counter that is incremented for every new connection, so what you described will not happen.
in tcpmain.c, tcpconn_new():
c->id=(*connection_id)++
What bothers me is what happens when an instance will have served INT_MAX connections (typically ~2.1 billions). But when it happens, I will be happy :).
Cheers
-
Camille Oudot -
Daniel-Constantin Mierla -
Olle E. Johansson -
Vitaliy Aleksandrov