18 Sep
2007
18 Sep
'07
8:43 p.m.
Juha Heinanen wrote:
Christian Schlatter writes:
Yes.
I was referring to an architecture where the mysql cluster is used to
share registration state between the proxies. For this, db_mode=3 is
required.
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.
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.
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.
/Christian
It doesn't matter if you have only one
registrar. But if you want to do
load-balancing/failover between multiple registrars, those registrars
should access the shared mysql cluster tables instead of their local
memory cache. If a phone registers with a proxy, the new registration
state has to be known to all registrars immediately.
if proxy x in the cluster receives registration request from a sip ua,
it saves it both in memory and (immediately (mode 1) or after a while
(mode 2)) into database, and then forwards the register request to other
proxies in the cluster that just save into memory. is that
"immediately" enough?