Re: [Serusers] more usrloc synchronization

Greger, thanks a lot. The problem with load balancer is that replies goes to the wrong server due to rewriting outgoing a.b.c.d . BTW, as Paul pointed, if you define some dummy interface with Virtual IP (VIP), there is no need to rewrite outgoing messages (I tested this a little). Why DNS approach is bad (except restricted NAT - let's say I am solving this)? I guess, Paul utilizes load-balancer scenario you have described. Believe there are only proprietary solutions for "the-replies-problem". We tried Vovida call-id-persistence package, unfortunately it didn't work for us. In my configuration I use shared remote DB cluster (with replication). Each ser see it as one-public-IP (exactly the approach you named for SIP). May be it's good idea to use local DB clusters, but if you have more than 2 servers your replication algorythm gonna be complex. Additional problem - it still doesn't solve usrloc synchronization - you still have to use t_replicate()... With regard to t_replicate() - it doesn't work for more than 2 servers, so I used exactly forward_tcp() and save_noreply() (you're absolutely right - this works fine so far); all sers are happy. Of course, this causes additional traffic. Interesting whether Paul's FIFO patch reduces traffic between sers? KRs, Tina, software engineer "Greger V. Teigre" <greger(a)teigre.com> wrote: Hi Tina, Thanks :-) I believe the load balancer can be in front and transparantly translate addresses in the SIP messages: User agent always sees a.b.c.d | Load balancer with public IP a.b.c.d | | ser1 (10.0.0.2) ser2 (10.0.0.3) Paul: You have a similar load-balancing solution, right? Do you use a commerical load balancer that you can reveal the name of? :-) The load balancer need to understand SIP (sort of) and use something (ex. IP address of user agent) to select SER server to send to and rewrite incoming to 10.0.0.2 and 10.0.0.3 respectively and outgoing to a.b.c.d. ser1 and ser2 will happily believe they are alone and communicate directly with user agent using their own private addresses. Both should know about all users (usrloc). Paul just recently posted a small patch for a setup where they use two-way replication between two mysql servers and where each SER instance will save all REGISTERs it receives from user agents, but only save to memory those replicated from the other SER peer. Klaus pointed out that the same can be done by not doing mysql replication, but have one DB for each SER and just use t_replicate() and save_noreply() (for two servers, for more than two you need to use forward_tcp()). I have heard complaints that this approach will generate too much network traffic. Also, t_replicate() does not guarantee delivery of the replication (forward_tcp is better, but not fool proof). So, the "best" solution would probably be to hope that Paul's recent TCP/UDP patch for network access to FIFO commands get included in the CVS. Then, a new replication module should use XMLRPC or whatever protocol the patch is using to forward (in a guaranteed mode) the usrloc information, which then would be injected directly into SER's memory, just like save() would, and of course in whatever db_mode you would like. The replicaton module would have to keep a queue (of course, flushed to a DB or something) in case of network problems, so that the replication would be done (sooner or later) regardless of problems. Of course, this is a major undertaking, so for most replication scenarioes, I would think the forward_tcp() + save_noreply() would work just fine. g-) --------------------------------- Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard.