:-) You never know where people are when they ask questions. Better start
with the basics... See inline comments.
Synchronization *to* a DB works of course out of the box (needed for
saving locations).
But for clustering you will need to synchronize your memory *from* the
DB or from the memory of the other nodes on the fly to get locations
from other nodes so you can lookup them again.
Yes, I did a quick look at the usrloc module code and can see that resync
from DB should be possible, but will probably take some time and I don't
think that is a good path.
Actually, Java Rocxx (Paul) and I tried to get a carrier-grade platform
discussion going in December, I think, but the reponse was not really there.
We don't use sql clusters, but have distributed data centers with IPsec
VPN connecting the centers. Each center is as self-contained as possible.
I think Paul mentioned that his approach was to use the FIFO queue with a
TCP/IP wrapper. An ul_add FIFO command to each server should probably do
the trick. I assume that the sql synchronization will not take less
bandwidth?! Unfortunately, Paul's company probably would like to keep their
solution secret, it's part of their commercial product. However, I would be
interested in a joint effort that could be contributed to the project. A
SOAP wrapper comes to mind as a solution to the network exchange, but maybe
even the SOAP exhange will add too much overhead? Well, probably not, but
just thinking out aloud here.
What would be the best replication implementation in ser? A new module?
The code would trigger a network exchange and would have to be forked.
Honestly, I haven't looked at the inner workings of ser, so I don't know.
Any pointers, anybody?
Locations
are not really that critical, are they? If you use
registration intervals of ex. 10 minutes, how do you even manage to
synchronize the databases manually?
We've about 20.000 users, which would result in ~2.900.000 successful
registrations per day or ~35 successful registerations per second, and
that means ~70 register messages per second (because of the
www_challenge).
Replicating on SIP layer means that every successful REGISTER has to
be sent to every server, so IMHO this just will not scale.
Excellent! Don't make it a problem until it is :-) Do you do load balancing
with DNS SRV or Vovida load balancer or similar? Is the MySQL cluster
networked or in the same physical location? (I don't know much about mySQL
clusters...)
Paul claimed voicemail to be their single, biggest problem, citing sems
to be the most promising. We don't even offer voicemail, but have looked at
voicemail solutions from the PSTN domain :-( How have you solved
voicemail?
And of course RTP proxy :-) I like rtpproxy because its simple, you
have good control and it's written in C. However, it has no load balancing
and you don't really have control over sessions (stats). It looks like most
large installation have chosen python-based mediaproxy due to these two
things (as well as video-stream support). Any thoughts?
g-)