Hi,
I'm looking for a mechanism to unregister clients when the corresponding TCP connection is closed, but had no success so far.
I've tried the handle_lost_tcp parameter of usrloc, but it didn't work: the user was not unregistered, whereas the connection was seen as closed by kamailio. Is it still a relevant option?
Otherwise, is there any mechanism that would trigger some kind of event_route whenever a connection (TCP, TLS, WS, WSS) is lost or closed?
Cheers,
Well, in websocket module you have the event route that's triggered when a connection is lost [1].
You wouldn't be able to use the unregister function of the registrar module, because a faked SIP message is used to trigger the event, but you can always write a custom SQL to delete the record of the location table using the socket information, to which you do have access: $si, $sp.
[1] http://kamailio.org/docs/modules/stable/modules/websocket.html#websocket.e.c...
Regards, Carlos
On Wed, Oct 22, 2014 at 8:08 AM, Camille Oudot camille.oudot@orange.com wrote:
Hi,
I'm looking for a mechanism to unregister clients when the corresponding TCP connection is closed, but had no success so far.
I've tried the handle_lost_tcp parameter of usrloc, but it didn't work: the user was not unregistered, whereas the connection was seen as closed by kamailio. Is it still a relevant option?
Otherwise, is there any mechanism that would trigger some kind of event_route whenever a connection (TCP, TLS, WS, WSS) is lost or closed?
Cheers,
Camille
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Le Wed, 22 Oct 2014 09:02:01 -0500, Carlos Ruiz Díaz carlos.ruizdiaz@gmail.com a écrit :
You wouldn't be able to use the unregister function of the registrar module, because a faked SIP message is used to trigger the event, but you can always write a custom SQL to delete the record of the location table using the socket information, to which you do have access: $si, $sp.
Yes indeed, in the case of websockets this event already exists. Then I can use a hash table to store the contact corresponding to the ip and port, then be able to unregister it from the usrloc database.
I was wondering if such a mechanism was available for plain TCP and TLS connections.
Cheers,
Hello,
On 22/10/14 15:08, Camille Oudot wrote:
Hi,
I'm looking for a mechanism to unregister clients when the corresponding TCP connection is closed, but had no success so far.
I've tried the handle_lost_tcp parameter of usrloc, but it didn't work: the user was not unregistered, whereas the connection was seen as closed by kamailio. Is it still a relevant option?
Otherwise, is there any mechanism that would trigger some kind of event_route whenever a connection (TCP, TLS, WS, WSS) is lost or closed?
it should work -- quickly looked to the code and couldn't spot a problem. Just be aware that is working only when usrloc keeps the records in memory (not designed for db only mode). Also, note that the record is not unregistered/removed immediately after the connection is closed, but by the timer task that checks for expired records.
Cheers, Daniel
Le Wed, 22 Oct 2014 16:12:12 +0200, Daniel-Constantin Mierla miconda@gmail.com a écrit :
it should work -- quickly looked to the code and couldn't spot a problem. Just be aware that is working only when usrloc keeps the records in memory (not designed for db only mode).
Ok, i'm using in memory storage, so it should be fine
Also, note that the record is not unregistered/removed immediately after the connection is closed, but by the timer task that checks for expired records.
Well, i configured usrloc with:
modparam("usrloc", "handle_lost_tcp", 1) modparam("usrloc", "timer_interval", 5)
then disconnect the SIP phone from the network, and here are the logs:
... DEBUG: <core> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0xa2a320, 13, -1, 0x10) fd_no=2 called DEBUG: <core> [tcp_read.c:1434]: release_tcpconn(): releasing con 0x7fedfe6cbe20, state 1, fd=13, id=3 DEBUG: <core> [tcp_read.c:1435]: release_tcpconn(): extra_data (nil) DEBUG: <core> [tcp_main.c:3331]: handle_tcp_child(): handle_tcp_child: reader response= 7fedfe6cbe20, 1 from 2 DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9e6080, 60, 2, 0x7fedfe6cbe20), fd_no=45 DEBUG: <core> [tcp_main.c:3459]: handle_tcp_child(): handle_tcp_child: CONN_RELEASE 0x7fedfe6cbe20 refcnt= 1 ...
but then, nothing from usrloc module.
It's maybe worth nothing that the kamailio instance dealing with these connections is not the registrar, but only a proxy in front of it, keeping track of successful registrations. The proxy's usrloc database is populated by calls to save() when a 200 OK response comes from the registrar box.
The Received information however is correctly set using the received_avp feature of the registrar module.
But is this "received" information used by the usrloc timer task, or does it remebers the source IP and port of the machine sending the 200 OK response instead?
Cheers,
On 22/10/14 18:19, Camille Oudot wrote:
Le Wed, 22 Oct 2014 16:12:12 +0200, Daniel-Constantin Mierla miconda@gmail.com a écrit :
it should work -- quickly looked to the code and couldn't spot a problem. Just be aware that is working only when usrloc keeps the records in memory (not designed for db only mode).
Ok, i'm using in memory storage, so it should be fine
Also, note that the record is not unregistered/removed immediately after the connection is closed, but by the timer task that checks for expired records.
Well, i configured usrloc with:
modparam("usrloc", "handle_lost_tcp", 1) modparam("usrloc", "timer_interval", 5)
then disconnect the SIP phone from the network, and here are the logs:
... DEBUG: <core> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0xa2a320, 13, -1, 0x10) fd_no=2 called DEBUG: <core> [tcp_read.c:1434]: release_tcpconn(): releasing con 0x7fedfe6cbe20, state 1, fd=13, id=3 DEBUG: <core> [tcp_read.c:1435]: release_tcpconn(): extra_data (nil) DEBUG: <core> [tcp_main.c:3331]: handle_tcp_child(): handle_tcp_child: reader response= 7fedfe6cbe20, 1 from 2 DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9e6080, 60, 2, 0x7fedfe6cbe20), fd_no=45 DEBUG: <core> [tcp_main.c:3459]: handle_tcp_child(): handle_tcp_child: CONN_RELEASE 0x7fedfe6cbe20 refcnt= 1 ...
but then, nothing from usrloc module.
It's maybe worth nothing that the kamailio instance dealing with these connections is not the registrar, but only a proxy in front of it, keeping track of successful registrations. The proxy's usrloc database is populated by calls to save() when a 200 OK response comes from the registrar box.
The Received information however is correctly set using the received_avp feature of the registrar module.
But is this "received" information used by the usrloc timer task, or does it remebers the source IP and port of the machine sending the 200 OK response instead?
It is internal connection id of the respective message (should be the REGISTER0 that is kept for this feature. In your case, it is not the right one, because you call save() for reply, so the connection would be the one on which reply came in (or none if it not tcp).
Maybe you can do save() when there is a register with credentials and unregister if there is a failure for relaying that registration (e.g., it was failure to authenticate in the next server). Cheers, Daniel
Le Wed, 22 Oct 2014 19:21:54 +0200, Daniel-Constantin Mierla miconda@gmail.com a écrit :
Maybe you can do save() when there is a register with credentials and unregister if there is a failure for relaying that registration (e.g., it was failure to authenticate in the next server).
Ok, this is so simple and so great at the same time :) Solved the issue for me, thanks.
-
Camille Oudot -
Carlos Ruiz Díaz -
Daniel-Constantin Mierla