[SR-Users] usrloc: Unregister client on TCP connection close

Daniel-Constantin Mierla miconda at gmail.com
Wed Oct 22 19:21:54 CEST 2014


On 22/10/14 18:19, Camille Oudot wrote:
> Le Wed, 22 Oct 2014 16:12:12 +0200,
> Daniel-Constantin Mierla <miconda at 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

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda




More information about the sr-users mailing list