Christian Schlatter writes:
What I don't like about replicating registration state through duplicated REGISTER messages, is the fact that a proxy's view of the registration state is not necessarily consistent with the other proxy's views. What if one of the proxies is not reachable for 10 minutes. It will be out of sync at least until all sip UAs who have registered while the proxy isn't reachable have re-registered.
yes, that can happen if another proxy is up, but not reachable. there is no problem if another proxy crashes and gets restarted, because if db_mode=1 is used, db is updated immediately exactly as with db_mode=3.
Also if you have to reboot a proxy, it will not learn the correct registration state upon boot as it would do if you would use db_mode=3 together with a distributed DB.
not true, if mode=1.
So, yes, you don't need db_mode=3 if you do REGISTER replication, but I'd recommend to use a distributed DB for replicating registration state.
unfortunately you then cannot support presence. using another proxy for presence is not a solution either, because same users need both presence and other sip methods.
by the way, looks like presence related requests are by far the most common ones if all sip UAs have presence turned on. it means that presence would also create biggest db activity.
-- juha