I've actually only ever encoutered one phone that didn't support DNS/SRV records, and it was total junk in a number of ways.
Mike On Thursday 07 December 2006 10:38, Christian Schlatter wrote: > Thomas Deillon wrote: > > Hi, > > > > I will try to summarise different load balancing solution and I hope > > that you will correct my mistake to have a good point of view of all > > solution. > > Thanks in advance. > > > > > > 1. Solution with DNS SRV allows making Load Balancing (on phone side) > > but need phones that support this function. > > 1.1: Explanation > > > > In your DNS, you can set DNS SRV entry like this: > > > > ------------------------------------------------------------------ > > > > |sipserver1.bigu.edu. 43200 IN A 10.0.0.21 > > |sipserver2.bigu.edu. 43200 IN A 10.0.0.22 > > |; > > |_sip._udp.bigu.edu. 43200 IN SRV 0 0 5060 sipserver1.bigu.edu. > > |_sip._udp.bigu.edu. 43200 IN SRV 0 0 5060 sipserver2.bigu.edu. > > > > ------------------------------------------------------------------- > > > > In your phone, you set in proxy SIP: "bigu.edu". The DNS will see that > > it's a request SIP in UDP and will return 1/2 times in this order: > > - sipserver1.bigu.edu. > > - sipserver2.bigu.edu. > > > > Phone understanding DNS SRV, will use the first line and if it doesn't > > work, will use the second one. > > The phone witch not understands the DNS SRV will always use the first > > line even if it doesn't work. > > > > Conclusion (C/c): It's a load balancing on phone side and so, if you > > can't choose phone model, it's not a solution (like IP centrex). > > To solve this problem, we have to use a load balancing on network side > > OR server side. > > I don't really agree with this conclusion. Load balancing/fail over "in > the previous hop" is surely the most scalable and reliable solution. And > it is well documented and standardized in RFC 3263 (Locating SIP > Servers) published in June 2002. SIP phones that do not support RFC 3263 > are IMHO not SIP compliant (although I have to admit that SIP compliance > is a somewhat fuzzy term). > > So before looking at "failover/load balancing in the redundant hop" > solutions like network level load balancers, I'd made *really* sure that > using phones that support 3263 is not an option. You will never reach > the same degree of scalability and no-bottleneck redundancy with these > solutions. > > Christian > > > 2. Solution with HA (Heart Beat) it's a solution on server side. > > 1.1 Explanation > > This solution is a fail over architecture. You will set a VIP (virtual > > IP address) for two servers. The server 1 will have this VIP and handle > > all the traffic. The second server will listen to the "heart" of the > > first server and it's something going wrong, it will take the VIP. > > > > C/c: This solution will not load balance traffic, and half of computer > > will not be used. > > > > 3. [Correct this part please] LVS (linux virtual Server) is a solution > > to load balance traffic but it's not SIP aware. You can use it for TCP > > connection but for SIP, it's very hard. > > However, you can set a load balancing on IP source, and so, each phone > > will see only one server. > > More than this, the LVS solution will not try to know if Asterisk OR SER > > is alive but try to know if the server is alive. (most of the time, only > > the service going down, not the whole server ...) > > > > C/c: The LVS is not a good solution. This can help but the reactivity is > > very bad. > > > > > > 4. RTPproxy with SER > > RTPproxy with Ser is use for failover and not load balancing, > > so, it's the same conclusion as HA. > > > > 5. MediaProxy with SERs. > > I'm really not sure, but I thing that we have to use only SER > > servers and the loadbalancer have to be a registrar server ?????? > > C/c: can you conclude... > > > > > > 6. The ultimate solution... > > I'm looking for a solution with SER (or something else) in > > loadbalancer and multiple Asterisk server behind it witch will do all > > SIP function (REGISTRAR, ...). > > This kind of architecture has to support NATed phones. > > > > > > > > Thanks to read this and thanks for your help, > > > > > > Thomas Deillon > > > > > > _______________________________________________ > > Users mailing list > > [email protected] > > http://openser.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/users
