#1.. most the failures and network bottle necks on asterisk in a 1k + user sip /iax are registrations polling's<br>you are right .. get SER ... dont be dumb.<br><br>#2 the config file with asterisk hardcode ips is a simple matter of running a script that parses it and puts in whatever it needs
<br><br><br><br>#3 basic failover will actually steal the ip form other box.. wich in this case would steal ip of down box.<br><br>#3b.. we need multiple listening addies.. since asterisk can only listen to one ip its sucks for now
<br><br><div><span class="gmail_quote">On 7/11/06, <b class="gmail_sendername">Alejandro Acosta</b> <<a href="mailto:alejandro.acosta@comsat.com.ve">alejandro.acosta@comsat.com.ve</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What about having the softphone/hardphones configured with a Main Asterisk server and an Alternative Asterisk Server?.<br><br>I just did a couple of tests with a Cisco ATA 186 and worked quit well after changing the RegInterval and Alternative Proxy Timeout.
<br><br>thks,<br><br>Alejandro,<br><br>On Tuesday 11 July 2006 05:04 am, unplug wrote:<br>> I have asked about it here. As Douglas said, it doesn't support<br>> mult-asterisk in current version.<br>> However, I have questions about why multi-asterisk so difficult to implement.
<br>> 1. As we can use ARA to store all information, sip user register info,<br>> dial plan ... to DB. All asterisks can use ARA to refer to the DB for<br>> necessary information even register information.<br>> 2. What is mean by "multiple Asterisk systems can't reference the same
<br>> MySQL database for SIP peers."? Does SIP peer information also store<br>> in DB?<br>> 3. Any difficulty to implement multiple asterisk?<br>> 4. If I want to implement multiple asterisk in some extent, how do I
<br>> begin? Any reference?<br>><br>><br>> On 7/11/06, RR <<a href="mailto:ranjtech@gmail.com">ranjtech@gmail.com</a>> wrote:<br>> > Interesting points on both messages<br>> ><br>> > 1) as far as multiple asterisk servers talking to the same database is
<br>> > concerned, I will have to test this out. I know nothing about the<br>> > database side of things, and a newbie on asterisk and linux so I have<br>> > no idea what and where the development of either of these are. From
<br>> > your message it sounds like it's just how ARA is designed because I<br>> > doubt it's to do with the ODBC driver itself. This will cause me a lot<br>> > of grief if you're right about this for multiple * servers to not be
<br>> > able to access the same database for peer lookup.<br>> ><br>> > 2) Clustering of DB isn't an issue, not for me at least. Haven't<br>> > tested this either but my DBs are clustered A/P providing a single
<br>> > entity to the internal systems. Might further look into a local DNS<br>> > lookup to add to this. I believe it's possible to do this in the MySQL<br>> > world with MySQL grid etc?<br>> ><br>
> > 3) I don't believe frequent registration is that big of an issue for<br>> > the network load it generates. Most providers out there set devices<br>> > for a 30-40secs Reg. Refresh to support NAT'ed endpoints and the a reg
<br>> > refresh is hardly about 300-400Byte pkts (I think). The math doesn't<br>> > add up for a major load esp. if you've got a load balancing mechanism<br>> > in front of your * boxes.<br>> ><br>
> > 4) I don't know enough about DUNDi to get into this discussion but<br>> > DUNDi just lookup extensions? or it also have any part to play in<br>> > registrations? If they just do extension lookup, then If DUNDi is
<br>> > implemented on an A/P pair of dedicated DUNDi lookup servers which<br>> > access a clustered database, then barring #1 being true, each * server<br>> > accesses the same database and pool of registrations. If registrations
<br>> > are refreshed frequently enough, the contact info in the database will<br>> > always be current and one server dying won't affect anything. At the<br>> > same time, they just consult the DUNDi lookup server for extension
<br>> > lookups instead of asking the database directly.<br>> ><br>> > 5) If you really want to improve on this, supplement your network with<br>> > SER as proxies and have them deal with Registrations and load-balance
<br>> > feature requests to * servers etc. Once * has done whatever it needs<br>> > to do (e.g. provide PBX features, voicemail, conference, IVR etc.) it<br>> > passes the call back to the Proxy to deal with the endpoints.
<br>> ><br>> > All depends on your scope and budget. If you want to have a SP grade<br>> > service then you need to breakout your functions.<br>> ><br>> > I just hope #1 isn't true though. The only alternative then would be
<br>> > to have /etc/asterisk reside on an NFS share or a CFS for all servers<br>> > to read massively huge conf files if you're catering for large number<br>> > of endpoints.<br>> ><br>> > Dunno if it helps anyone or I'm just shooting sh*t ;)
<br>> > _______________________________________________<br>> > --Bandwidth and Colocation provided by <a href="http://Easynews.com">Easynews.com</a> --<br>> ><br>> > asterisk-users mailing list<br>
> > To UNSUBSCRIBE or update options visit:<br>> > <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>> ><br>> _______________________________________________
<br>> --Bandwidth and Colocation provided by <a href="http://Easynews.com">Easynews.com</a> --<br>><br>> asterisk-users mailing list<br>> To UNSUBSCRIBE or update options visit:<br>> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">
http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>><br>_______________________________________________<br>--Bandwidth and Colocation provided by <a href="http://Easynews.com">Easynews.com</a> --<br><br>asterisk-users mailing list
<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></blockquote></div><br><br clear="all"><br>
-- <br>Mike<br>Sales Manager<br><a href="http://www.theclubvoip.com">http://www.theclubvoip.com</a><br>Making it happen<br>1.888.470.7253