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 <[EMAIL PROTECTED]> 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
