22 Dec
2011
22 Dec
'11
9:02 p.m.
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.
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.
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.
Regards,
Ovidiu Sas