G'day listers, Well, I just found this one: http://svn.digium.com/view/asterisk/team/russell/events/doc/distributed_devstate.txt?view=markup
Time to read. On Tue, Sep 9, 2008 at 2:29 PM, Nguyen <[EMAIL PROTECTED]> wrote: > Dear Tilghman, > > Thanks for your feedback. Scratching my head to see how to turn the > standalone box to something more scalable. func_odbc , mysql in > dialplan, all are missing the states of devices, agents... etc > > Realtime, as far as it goes, also touch only one part of asterisk, by > storing all the reginfo in db. If we want to move further, and > touching the states, we have to dig in. > > We understand that for asterisk as it is, local db1 is good enough. > Maybe Digium can take another look at the problem. > > Will keep you in touch with progress, if any :) > > > > On 9/9/08, Tilghman Lesher <[EMAIL PROTECTED]> wrote: > > 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 > > > > _______________________________________________ > > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > > > AstriCon 2008 - September 22 - 25 Phoenix, Arizona > > Register Now: http://www.astricon.net > > > > asterisk-users mailing list > > To UNSUBSCRIBE or update options visit: > > http://lists.digium.com/mailman/listinfo/asterisk-users > > > > > -- > With best regards, > Nguyen > -- With best regards, Nguyen
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
