Hi listers, We want to implement one call center with asterisk. The idea is it should be scalable, with openser as an dispatcher and bunch of asterisk servers to do ACD, Queues, Agents things... Easy to say :( Look closely to the current asterisk, we do see some problem: - SIP registrations was stored in astdb. - And queue members also was stored in astdb. - ... asterisk was built as standalone PBX, so it's understandable. Is it time to replace astdb with something like MySQL, so all asterisk boxes in cluster can have identical access to all the informations, devstates, etc...? Our first thought is replacing the astdb implementation, currently with DB1, with MySQL. app_dbodbc is a hint, but there are still many things to consider: concurrency access from many box to same row, performance issues, ... We need your pointers here. Where are the caveats? Is it the correct way to start add clustering capabilities to asterisk? Your replies are much appreciated, -- With best regards, Nguyen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080909/4ac642a3/attachment.htm
On Tue, 9 Sep 2008, Nguyen wrote:> Hi listers, > > We want to implement one call center with asterisk. The idea is it should be > scalable, with openser as an dispatcher and bunch of asterisk servers to do > ACD, Queues, Agents things... Easy to say :( > > Look closely to the current asterisk, we do see some problem: > > - SIP registrations was stored in astdb. > - And queue members also was stored in astdb. > - ... > > asterisk was built as standalone PBX, so it's understandable. > > Is it time to replace astdb with something like MySQL, so all asterisk boxes > in cluster can have identical access to all the informations, devstates, > etc...?No. Please do not replace astdb. Provide a differenet mechanism if you need to, (at compile time?) but please leave astdb as it is for those of us who use it and like it as it is. It's simple, fast, and for 99% of installations, it's just fine. Gordon
On Monday 08 September 2008 12:43:53 Nguyen wrote:> Hi listers, > > We want to implement one call center with asterisk. The idea is it should > be scalable, with openser as an dispatcher and bunch of asterisk servers to > do ACD, Queues, Agents things... Easy to say :( > > Look closely to the current asterisk, we do see some problem: > > - SIP registrations was stored in astdb. > - And queue members also was stored in astdb. > - ... > > asterisk was built as standalone PBX, so it's understandable. > > Is it time to replace astdb with something like MySQL, so all asterisk > boxes in cluster can have identical access to all the informations, > devstates, etc...? > > Our first thought is replacing the astdb implementation, currently with > DB1, with MySQL. app_dbodbc is a hint, but there are still many things to > consider: concurrency access from many box to same row, performance issues, > ... > > We need your pointers here. Where are the caveats? Is it the correct way to > start add clustering capabilities to asterisk? > > Your replies are much appreciated,There are some very major issues with trying to replace astdb with any other backend. One possibility which has been floated is to replace the DB1 implementation with sqlite, as the backend is still a Berkeley database, while having the advantages of a SQL interface layer. An implementation has been coded, though we've held off on committing such a change until we have the ability to convert an old db1-based database to a sqlite-based database. I would highly recommend, though, that you do not attempt to replace db1 with MySQL for this purpose. There are some higher level databases where it may make good sense to go with MySQL as your backend (such as for Realtime database maintenance), but astdb is most certainly not one of them. In addition, you may want to look at func_odbc for an additional interface from the dialplan to your database. -- Tilghman