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
