Re: [SR-Users] [sr-dev] new feature: option to remove contacts based on sip nat keepalives

Hello, over the weekend I committed the code that allows to remove contacts from location table if the device does not respond to several attempts of SIP nat keepalives (usually OPTIONS requests). The feature works only for SIP over UDP, being the only transport for which nathelper module sends keepalives (or sip ping requests as written in some docs). Also, the lack of keepalive reply is tracked only for location records stored in memory (so it does not work with db only mode for usrloc). This is because the keepalives are sent stateless, not using tm module, to avoid overloading of timers and shared memory when dealing with large subscriber base -- therefore the implementation is very lightweight in using resources, targeting of course scalability. Detection of replies for keepalives is done based on from tag which carries the internal unique id of the location contact (which is available from v3.3). In order to enable this feature you have to set the keepalive_timeout parameter of nathelper module -- that's the only addition you have to add to a config that sends SIP nat keepalives. Internally, the modules store the timestamp of the last SIP keepalive reply (nathelper detects the right reply and calls usrloc API for storing the timestamp in contact structure in memory). http://kamailio.org/docs/modules/devel/modules_k/nathelper.html#id2535244 Before sending a new keepalive to a contact, it is checking if the last keepalive reply is older than keepalive_timeout value and if yes, will lower the expires to 10 seconds (if the expires is higher). There is no special handling of keepalive reply codes, all of them will update the last keepalive timestamp. This feature should be useful in mobile networks, to avoid stacking lot of invalid contacts which could result in lot of branches causing many retransmissions. There is plant to go for tcp/tls as well and detect when the connection is down, but looks like no spare time in the near future. However, right now using set_forward_no_connect() will avoid trying to create new connections for natted uses whose registration connection is down.