<div dir="ltr"><div><div>as Sergey has proposed, there could be a DNS service which monitors the availability of your VoIP servers and changes the DNS entries if a server goes down. The TTL for individual SRV records could be set to few seconds.<br><br></div>But that means again that all users are using the same server, so it&#39;s not really a distributed model as Emrah challenged in the original mail.<br><br></div>Probably this new project will help in building a distributed cluster, but it needs a detailed study:  <a href="https://ipfs.io/">https://ipfs.io/</a><br><br><br><br><br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 12, 2016 at 10:09 AM, Andrew Cassidy <span dir="ltr">&lt;<a href="mailto:andrew@cassidywebservices.co.uk" target="_blank">andrew@cassidywebservices.co.uk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It&#39;s not instant, but I&#39;ve used OVH failover IP&#39;s to do that sort of thing. Heartbeat over ipsec tunnel, use pacemaker with a custom script that does the OVH API call to move the IP address.<div><br></div><div>Sadly it&#39;s not that quick, takes about 2 minutes.</div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On 12 February 2016 at 07:40, Stanislav Sinyagin <span dir="ltr">&lt;<a href="mailto:ssinyagin@gmail.com" target="_blank">ssinyagin@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">there is an issue with anycast routing though: when you bring up a new<br>
server, some running sessions will be dropped, because their IP<br>
packets would be routed to a different host. So, it needs a careful<br>
design. Maybe place only the SIP proxy on an anycast address, and run<br>
the calls from unique local addresses.<br>
<br>
<br>
Multiple DNS SRV records with different priorities are also possible,<br>
but you can&#39;t direct the users to the nearest location within the same<br>
domain. Also a bunch of SIP clients needs to be tested and you need to<br>
answer the questions, like:<br>
<br>
-- what is the timeout if the primary server is unavailable?<br>
-- if the primary host goes down during the call, how soon can the<br>
client re-dial?<br>
-- what happens if the primary server comes up again?<br>
<div><div><br>
<br>
<br>
<br>
<br>
<br>
On Thu, Feb 11, 2016 at 8:00 PM, Stanislav Sinyagin &lt;<a href="mailto:ssinyagin@gmail.com" target="_blank">ssinyagin@gmail.com</a>&gt; wrote:<br>
&gt; hi Emrah and all,<br>
&gt;<br>
&gt; it&#39;s the first time I actually searched for it, but there are hosting<br>
&gt; offers with anycast IP routing. It means, you have multiple servers in<br>
&gt; various locations, and they share the same service IP address. The<br>
&gt; clients connect to the nearest server, which is determined by standard<br>
&gt; BGP routing. You are still limited to a single global hosting<br>
&gt; provider, but you benefit from its redundant network and geographical<br>
&gt; distribution.<br>
&gt;<br>
&gt; In case of anycast addressing, incoming connections will be served<br>
&gt; easily. But the outgoing connections are rather tricky: you will need<br>
&gt; to bring the outbound call to the physical server where the user has<br>
&gt; registered, and initiate the connection from its anycast address. So,<br>
&gt; you can share and replicate the registration database, but you need to<br>
&gt; send the outbound call to the server which accepted the registration.<br>
&gt; I guess you should be able to retrieve this information from the<br>
&gt; registration database. This needs to be looked in details.<br>
&gt;<br>
&gt; Google for anycast server hosting, and there are at least 3 providers<br>
&gt; offering virtual hosts, and OVH is offering physical hosts as well. I<br>
&gt; guess there are more providers with similar offerings.<br>
&gt;<br>
&gt;<br>
&gt; Without anycast, you would need to use redundant registrars sharing<br>
&gt; the same service IP address -- for example, Digitalocean offers such<br>
&gt; service within any single datacenter.<br>
&gt;<br>
&gt; Having multiple registrars with different IP addresses is also<br>
&gt; possible, but then you depend on the way how each particular SIP<br>
&gt; client handles multiple IP addresses after resolving the domain name.<br>
&gt; Some of them may get stuck to a single address, even if it&#39;s not<br>
&gt; responding.<br>
&gt;<br>
&gt;<br>
&gt; cheers,<br>
&gt; stanislav<br>
&gt;<br>
&gt; On Thu, Feb 11, 2016 at 5:53 PM, Emrah &lt;<a href="mailto:lists@kavun.ch" target="_blank">lists@kavun.ch</a>&gt; wrote:<br>
&gt;&gt; Hi list,<br>
&gt;&gt; I’m writing to gather your thoughts and suggestions on how to have a high availability FS setup on different networks.<br>
&gt;&gt;<br>
&gt;&gt; I am trying to achieve the following:<br>
&gt;&gt;  - Load balance FreeSWITCH instances on 2 or more servers, possibly in different countries.<br>
&gt;&gt; - Shared user directory and dialplan, but I’m not sure if shared registrations would make sense.<br>
&gt;&gt; - If a server goes down, the phone should register on the alternative servers. Obviously we can’t keep calls up.<br>
&gt;&gt;<br>
&gt;&gt; I’m obviously not the first one out there doing this. I’m trying to learn from those who’ve come up with reliable solutions.<br>
&gt;&gt;<br>
&gt;&gt; I’ve tried sharing a registration table among multiple FS instances. But it was a beginners mistake. Even with the right path to reach the client, only the invites sent from the server used by the phone would be processed.<br>
&gt;&gt; If my phone registers on server A, then server A shares the info with server B, server B knows how to contact the phone but it won’t be able to. Supposedly because of NAT issues.<br>
&gt;&gt;<br>
&gt;&gt; I am aiming for fully independent FS instances that can back each other up and be used independently. I am guessing this would require some sort of SBC or external registrar server with a Kamailio or Repro.<br>
&gt;&gt;<br>
&gt;&gt; Anyway just trying to spark the conversation around this subject and hopefully we can come up with a formula that can help many with their FS deployments. My provider’s network just went all down in IPv4 and HA behind the same provider proved to be useless.<br>
&gt;&gt;<br>
&gt;&gt; Best,<br>
&gt;&gt; E<br>
&gt;&gt; _________________________________________________________________________<br>
&gt;&gt; Professional FreeSWITCH Consulting Services:<br>
&gt;&gt; <a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
&gt;&gt; <a href="http://www.freeswitchsolutions.com" rel="noreferrer" target="_blank">http://www.freeswitchsolutions.com</a><br>
&gt;&gt;<br>
&gt;&gt; Official FreeSWITCH Sites<br>
&gt;&gt; <a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
&gt;&gt; <a href="http://confluence.freeswitch.org" rel="noreferrer" target="_blank">http://confluence.freeswitch.org</a><br>
&gt;&gt; <a href="http://www.cluecon.com" rel="noreferrer" target="_blank">http://www.cluecon.com</a><br>
&gt;&gt;<br>
&gt;&gt; FreeSWITCH-users mailing list<br>
&gt;&gt; <a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
&gt;&gt; <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
&gt;&gt; UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
&gt;&gt; <a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" rel="noreferrer" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" rel="noreferrer" target="_blank">http://confluence.freeswitch.org</a><br>
<a href="http://www.cluecon.com" rel="noreferrer" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a></div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr"><b>Andrew Cassidy BSc (Hons) MBCS SSCA</b><div>Managing Director<div><div><img src="http://www.cassidywebservices.co.uk/static/emailsig.png"><br></div><div><br><div><b style="color:rgb(51,135,171);text-decoration:none;font-family:sans-serif"><a href="mailto:info@cassidywebservices.co.uk" style="color:rgb(51,135,171);text-decoration:none;font-family:sans-serif" target="_blank">T</a> </b>03300 100 960 
<b style="color:rgb(51,135,171);text-decoration:none;font-family:sans-serif"><a href="mailto:info@cassidywebservices.co.uk" style="color:rgb(51,135,171);text-decoration:none;font-family:sans-serif" target="_blank">F</a> </b>03300 100 961</div><div><b style="text-decoration:none;font-family:sans-serif"><a href="mailto:info@cassidywebservices.co.uk" style="color:rgb(51,135,171);text-decoration:none;font-family:sans-serif" target="_blank">E</a> </b><a href="mailto:andrew@cassidywebservices.co.uk" target="_blank">andrew@cassidywebservices.co.uk</a></div><div><b style="text-decoration:none;font-family:sans-serif"><a href="mailto:info@cassidywebservices.co.uk" style="color:rgb(51,135,171);text-decoration:none;font-family:sans-serif" target="_blank">W</a> </b><a href="http://www.cassidywebservices.co.uk" target="_blank">www.cassidywebservices.co.uk</a></div></div></div></div></div></div>
</font></span></div>
<br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" rel="noreferrer" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" rel="noreferrer" target="_blank">http://confluence.freeswitch.org</a><br>
<a href="http://www.cluecon.com" rel="noreferrer" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br></blockquote></div><br></div>