:-) You never know where people are when they ask questions. Better start with the basics... See inline comments.
Have a look at: http://www.iptel.org/ser/doc/modules/html/usrloc.html#AEN153
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-)