And should a synced AstDB database work to keep all phones registered in the second server?<br>Wouldn't be preferred something like DUNDI or whatever?<br><br>Thanks,<br>Ricardo Carvalho.<br><br><br><br><br><div class="gmail_quote">
On Jan 9, 2008 11:14 AM, Julian J. M. <<a href="mailto:julianjm@gmail.com">julianjm@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
You can use DRBD for keeping a synced AstDB (/var/lib/asterisk/astdb)<br>between both systems. Although you'll need heartbeat for mounting the<br>DRBD partition when the standby machine becomes active.<br><br>Julián J. M.
<br><div><div></div><div class="Wj3C7c"><br>On Jan 9, 2008 11:10 AM, Ricardo Carvalho <<a href="mailto:rjcarvalho@gmail.com">rjcarvalho@gmail.com</a>> wrote:<br>> I thought that even working with realtime sip, SIP peers registration is
<br>> kept in astDB (as running memory for asterisk), because I have a problem<br>> related to this - even with mysql databases synced with mysql replication,<br>> when my standby machine assumes production, none of my phones are known by
<br>> the Asterisk running in the backup machine that assumes production, and so,<br>> I had to make a script to reboot all phones when the standby machine enters<br>> production so that they register with the backup server's Asterisk.
<br>><br>> Can this be done some other way? Is it DUNDI, regexten or regcontext usefull<br>> to avoid rebooting all phones so that they register again?<br>><br>> Thanks in advance,<br>> Ricardo Carvalho.
<br>><br>><br>><br>><br>> On Jan 9, 2008 9:46 AM, Johansson Olle E <<a href="mailto:oej@edvina.net">oej@edvina.net</a>> wrote:<br>> ><br>> > 9 jan 2008 kl. 10.42 skrev Yehavi Bourvine +972-8-9489444:
<br>> ><br>> ><br>> ><br>> ><br>> > > Hello,<br>> > ><br>> > > I know this is not a pure High Availability question, but I think<br>> > > it is<br>> > > related...
<br>> > ><br>> > > I would like to do load balancing between two Asterisk servers and<br>> > > allow the<br>> > > phones to use the other server as backup. Asterisk is installed on<br>
> > > both<br>> > > systems, the users (extensions) are defined in MySQL database<br>> > > (realtime<br>> > > Asterisk); the MySQL database is replicated on both systems.<br>> > >
<br>> > > What I see is that only the server to which the phone registered<br>> > > knows about<br>> > > its location. The other server doesn't know it, and thinks that the<br>> > > phone is
<br>> > > offline (although I see its current address in the MySQL record).<br>> > ><br>> > > The realtime section of SIP.CONF is as follows:<br>> > ><br>> > > rtcachefriends=yes
<br>> > > rtsavesysname=yes<br>> > > rtupdate=yes<br>> > > rtautoclear=yes<br>> > > ignoreregexpire=yes<br>> > ><br>> > > I tried setting rtsavesysname=no but it didn't change the behaviour.
<br>> > > Any idea<br>> > > what I am doing wrong, or how to do it?<br>> > ><br>> > > BTW, I tried to code the dialplan to check the sysname field in<br>> > > MySQL; if it<br>
> > > finds that the phone is on the other server then to direct the call<br>> > > to there.<br>> > > However, it then fails authentication (even if I set bith servers to<br>> > > be<br>
> > > "insecure") :-(<br>> ><br>> > This is why we have Dundi :-) and the regexten= parameter in channel<br>> > drivers.<br>> ><br>> > I don't understand why you fail authentication between the servers,
<br>> > but that's propably just<br>> > a configuration issue that you can solve.<br>> ><br>> > You can do a lookup in the Msyql table, since the server who receives<br>> > the registration will store it in the database. In newer versions of
<br>> > Asterisk, you also have the option of storing the system name of the<br>> > server, so that you can redirect the call through that server out to<br>> > the client. With NAT, you have to send the call from the same IP
<br>> > address in order to reach the client.<br>> ><br>> > /O<br>> ><br>> ><br>> ><br>> ><br>> > _______________________________________________<br>> > --Bandwidth and Colocation Provided by
<a href="http://www.api-digital.com--" target="_blank">http://www.api-digital.com--</a><br>> ><br>> > asterisk-ha-clustering mailing list<br>> > To UNSUBSCRIBE or update options visit:<br>> > <a href="http://lists.digium.com/mailman/listinfo/asterisk-ha-clustering" target="_blank">
http://lists.digium.com/mailman/listinfo/asterisk-ha-clustering</a><br>> ><br>><br>><br>> _______________________________________________<br>> --Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--" target="_blank">
http://www.api-digital.com--</a><br>><br>> asterisk-ha-clustering mailing list<br>> To UNSUBSCRIBE or update options visit:<br>> <a href="http://lists.digium.com/mailman/listinfo/asterisk-ha-clustering" target="_blank">
http://lists.digium.com/mailman/listinfo/asterisk-ha-clustering</a><br>><br><br><br><br></div></div><font color="#888888">--<br><a href="http://www.julianmenendez.es" target="_blank">http://www.julianmenendez.es</a><br>
</font><div><div></div><div class="Wj3C7c"><br>_______________________________________________<br>--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--" target="_blank">http://www.api-digital.com--</a>
<br><br>asterisk-ha-clustering mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-ha-clustering" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-ha-clustering
</a><br></div></div></blockquote></div><br>