> 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

Reply via email to