[Users] MediaProxy / RTPproxy / SER / Asterisk / HA / LVS / DNS [load-balancing and high availability]

[Mike Williams]

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
> > Users at openser.org
> > http://openser.org/cgi-bin/mailman/listinfo/users