8 Dec
2006
8 Dec
'06
5:45 a.m.
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(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users