[asterisk-users] Server redundancy

Tue Jul 11 11:34:07 MST 2006

#1.. most the failures and network bottle necks on asterisk in a 1k + user
sip /iax are registrations polling's
you are right .. get SER ... dont be dumb.

#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

#3 basic failover will actually steal the ip form other box.. wich in this
case would steal ip of down box.

#3b.. we need multiple listening addies.. since asterisk can only listen to
one ip its sucks for now

On 7/11/06, Alejandro Acosta <alejandro.acosta at comsat.com.ve> wrote:
>
> 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
> >
> _______________________________________________
> --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
>

-- 
Mike
Sales Manager
http://www.theclubvoip.com
Making it happen
1.888.470.7253
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060711/e67ae907/attachment.htm