[asterisk-users] Server redundancy

[Alejandro Acosta]

What about having the softphone/hardphones configured with a Main Asterisk server and an Alternative Asterisk Server?.

I just did a couple of tests with a Cisco ATA 186 and worked quit well after changing the RegInterval and Alternative Proxy Timeout.

thks,

Alejandro,

On Tuesday 11 July 2006 05:04 am, unplug wrote:
> I have asked about it here. As Douglas said, it doesn't support
> mult-asterisk in current version.
> However, I have questions about why multi-asterisk so difficult to implement.
> 1. As we can use ARA to store all information, sip user register info,
> dial plan ... to DB.  All asterisks can use ARA to refer to the DB for
> necessary information even register information.
> 2. What is mean by "multiple Asterisk systems can't reference the same
> MySQL database for SIP peers."?  Does SIP peer information also store
> in DB?
> 3.  Any difficulty to implement multiple asterisk?
> 4. If I want to implement multiple asterisk in some extent, how do I
> begin?  Any reference?
> 
> 
> On 7/11/06, RR <ranjtech at gmail.com> wrote:
> > Interesting points on both messages
> >
> > 1) as far as multiple asterisk servers talking to the same database is
> > concerned, I will have to test this out. I know nothing about the
> > database side of things, and a newbie on asterisk and linux so I have
> > no idea what and where the development of either of these are. From
> > your message it sounds like it's just how ARA is designed because I
> > doubt it's to do with the ODBC driver itself. This will cause me a lot
> > of grief if you're right about this for multiple * servers to not be
> > able to access the same database for peer lookup.
> >
> > 2) Clustering of DB isn't an issue, not for me at least. Haven't
> > tested this either but my DBs are clustered A/P providing a single
> > entity to the internal systems. Might further look into a local DNS
> > lookup to add to this. I believe it's possible to do this in the MySQL
> > world with MySQL grid etc?
> >
> > 3) I don't believe frequent registration is that big of an issue for
> > the network load it generates. Most providers out there set devices
> > for a 30-40secs Reg. Refresh to support NAT'ed endpoints and the a reg
> > refresh is hardly about 300-400Byte pkts (I think). The math doesn't
> > add up for a major load esp. if you've got a load balancing mechanism
> > in front of your * boxes.
> >
> > 4) I don't know enough about DUNDi to get into this discussion but
> > DUNDi just lookup extensions? or it also have any part to play in
> > registrations? If they just do extension lookup, then If DUNDi is
> > implemented on an A/P pair of dedicated DUNDi lookup servers which
> > access a clustered database, then barring #1 being true, each * server
> > accesses the same database and pool of registrations. If registrations
> > are refreshed frequently enough, the contact info in the database will
> > always be current and one server dying won't affect anything. At the
> > same time, they just consult the DUNDi lookup server for extension
> > lookups instead of asking the database directly.
> >
> > 5) If you really want to improve on this, supplement your network with
> > SER as proxies and have them deal with Registrations and load-balance
> > feature requests to * servers etc. Once * has done whatever it needs
> > to do (e.g. provide PBX features, voicemail, conference, IVR etc.) it
> > passes the call back to the Proxy to deal with the endpoints.
> >
> > All depends on your scope and budget. If you want to have a SP grade
> > service then you need to breakout your functions.
> >
> > I just hope #1 isn't true though. The only alternative then would be
> > to have /etc/asterisk reside on an NFS share or a CFS for all servers
> > to read massively huge conf files if you're catering for large number
> > of endpoints.
> >
> > Dunno if it helps anyone or I'm just shooting sh*t ;)
> > _______________________________________________
> > --Bandwidth and Colocation provided by Easynews.com --
> >
> > asterisk-users mailing list
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-users
> >
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>