25 Feb
2015
25 Feb
'15
8:05 p.m.
Hi,
I want to propose a patch to usrloc:
https://github.com/kamailio/kamailio/commit/14852a98ed46b7a88c92bff31c319d2…
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,
--
Camille
26 Feb
26 Feb
8:57 a.m.
On 25 Feb 2015, at 19:05, Camille Oudot <camille.oudot(a)orange.com> wrote:
Hi,
I want to propose a patch to usrloc:
https://github.com/kamailio/kamailio/commit/14852a98ed46b7a88c92bff31c319d2…
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?
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
12:11 p.m.
Le Thu, 26 Feb 2015 07:57:49 +0100,
"Olle E. Johansson" <oej(a)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.
--
Camille
12:18 p.m.
On 26/02/15 11:11, Camille Oudot wrote:
Le Thu, 26 Feb 2015 07:57:49 +0100,
"Olle E. Johansson" <oej(a)edvina.net> a écrit :
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
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
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.
2 Mar
2 Mar
3:27 p.m.
Le Thu, 26 Feb 2015 11:18:39 +0100,
Daniel-Constantin Mierla <miconda(a)gmail.com> a écrit :
On 26/02/15 11:11, Camille Oudot wrote:
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/42dc7c8d17612b9d7a2dfa68bc9eb47…
I plan to merge it into master if it's fine with you.
Cheers,
--
Camille
Le Thu, 26 Feb 2015 07:57:49 +0100,
"Olle E. Johansson" <oej(a)edvina.net> a écrit :
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). 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.
23 Mar
23 Mar
5:31 p.m.
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.
Hi,
I want to propose a patch to usrloc:
https://github.com/kamailio/kamailio/commit/14852a98ed46b7a88c92bff31c319d2…
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,
5:48 p.m.
Le Mon, 23 Mar 2015 17:31:33 +0200,
Vitaliy Aleksandrov <vitalik.voip(a)gmail.com> a écrit :
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.
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
3535
days inactive
3561
days old
6 comments
4 participants
participants (4)
-
Camille Oudot -
Daniel-Constantin Mierla -
Olle E. Johansson -
Vitaliy Aleksandrov