> 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 _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users