Greger V. Teigre wrote:
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.
Yes, either you'll lose the fast memory access if always looking up the DB or you synch back from the DB periodically which would mean that it could be the case that a location isn't up to date or has expired on a node.
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.
Also a possible approach, maybe we should think about something like that.
I assume that the sql synchronization will not take less bandwidth?!
A rough estimate shows that it's at least less then sending a SIP message. In fact it's more or less the sql statement that has to be transmitted.
But basically in my case I don't see the network as bottleneck since all our equipment is located in a 100MBit LAN.
A SOAP wrapper comes to mind as a solution to the network exchange, but maybe even the SOAP exhange will add too much overhead?
We currently handle call forwards (conditional and unconditional) with location databases too, and here a cronjob runs every minute for inserting the CFC and CFUC locations by calling serctl (so it's related to Paul's approach of location handling, we just don't use the FIFO directly).
But it's planned to use SOAP for realtime provisioning of this stuff, so thanks for the hint, maybe this could be done with the location database too. For this a kind of soap module would be great to prevent exec_msg calls for each registration. Of course also just thinking loud ;o)
Do you do load balancing with DNS SRV or Vovida load balancer or similar?
It's currently DNS SRV, but I'd like to set up some kind of load balancer (maybe based on http://www.linuxvirtualserver.org/software/ipvs.html), just because so much UACs don't get the SRV handling right, and it's always a fight to get potential new UAC vendors to fix it.
Is the MySQL cluster networked or in the same physical location? (I don't know much about mySQL clusters...)
It will be in the same VLAN. MySQL clustering is still beta, so a first step would a simple replication (let the SERs write their locations into the master database and lookup the location in the local slave databases), because replication works well with MySQL. The master database could be secured by a heartbeat cluster.
The advantage of the MySQL cluster would be that the SERs could write also into their local database. But maybe it would generally be a good idea to move the databases to own dedicated machines. We'll see.
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?
We use Asterisk for voicemail. The asterisk instances run on the same machine as the SERs, and a SER always redirects voicemail calls to the local Asterisk, with a failure route to a second one. Not that redundant and scaleable, but I don't see voicemail as operation critical as normal call routing. The voicemail storage is shared via NFS by the way.
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?
We use mediaproxy here, because it's scalable via DNS SRV and it supports T.38 (I sent a patch to the serdev list some months ago to handle reinvites, and the guys at AG Projects thought about implementing something like that, but I haven't heard anything about that since then).
Cheers, Andy