[Serusers] SER-Redundancy by Master/Slave-Location-DB

[Greger V. Teigre]

:-) 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-)