[SR-Users] usrloc, timer process and cache cleanup

[Daniel-Constantin Mierla]

On 12/22/11 8:02 PM, Ovidiu Sas wrote:
>> Right, that has to be done, but there are some cases when db can become
>> inconsistent, due to database unavailability, and then some trick have to be
>> done at db layer, example:
>>
>> - db is unavailable, phone unregisters, contact deleted from memory but not
>> from database
>> - phone register again, usrloc will try insert and will fail - in this case
>> it should be update if insert fails (or replace)
> If the phone registers again, it should be a brand new entry
> (different Call-ID, CSeq and so on).
> The leftover entry on the db will be cleanup on a server restart.

According to sip specs, the key is the contact address, thus operations 
are done on (aor, contact). In kamailio you can configure to match using 
call id (plus path) as well, but is not the default since it breaks the 
specs.
>
>> The other way around could happen when mistakenly deleting/changing records in db, which should not happen, but Murphy says opposite.
> If someone is messing with the db, kamailio shouldn't try to correct
> admin mistakes.

It was just an example, I haven't gone to all corner cases that can 
happen from human or (self or different) application errors. There were 
couple of similar reports in the past, related to conflicts of 
insert/update, update/insert, delete/update a.s.o. cases, so I proposed 
to go for a portable solution, not for one which valid to a db driver 
only -- configurable or not, is different thing than the specific topic.


> I think that the replace solution should be a last resort.
> If implemented, should be configurable.  I would rather see the
> original issue instead of being masked and let it trigger other issues
> later on which would be more difficult to debug.
I think the goal is to have coherent, consistent and persistent records 
in location table, so that lookup is always valid and restarts don't 
lose records. In no case you get any feedback implicitly, this is either 
about logging or malfunctioning. Perhaps is better to get a log message 
to investigate and have all keep going, than the second.

Cheers,
Daniel

> -- 
> Daniel-Constantin Mierla -- http://www.asipto.com
> http://linkedin.com/in/miconda -- http://twitter.com/miconda