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