Details: ser caches user lcoations, that means, if it lookup() a user, ser does not query the database as the user lcoations are stored in RAM. New REGISTER are stored by save(). The writeback into the database can be done immediately (safe, but slower) or delayed (not so safe, but faster). more info on this can be found in the README of the userloc module. So, now you know the basics to build up your system, e.g: - 2 proxies + data bases --------------+ replicated REGISTER +------------+ | active proxy| -------------------------> |backup proxy| --------------+ +------------+ | | | | | | |data |data |base |base |write |write |through |through | | V V ----------------+ +---------------+ |active database| |backup database| ----------------+ +---------------+ if the active proxy or database fails, you have to switch over to the bakup combination (manually or autmatically). You could also use only one database, but than only the active proxy is allowed to save() to the database. You could also make the database failover transparent to the SIP proxy: 2 databases with replication enabled, and if the main one fails, the backup db takes the IP address of the failed one. So, these are some theoretical solutions. I hope the guys which uses ser in production environments have some comments on this. regards, Klaus PS: always CC to the list simple wrote: