Re: [asterisk-users] replace astdb with a cluster-capable sql database engine
--- Vieri [EMAIL PROTECTED] wrote: Would it be possible to modify the API calls that are currently going to the AstDB code within Asterisk, and put a translation layer to have them use the func_odbc instead (or either one)? At a lower level, for everything Asterisk does to its AstDB, maybe there could be a system setting which allows the user to say, ok, use DB, or, no, use func_odbc (not at the dialplan level). What I mean is that ast_db_put and similar calls are about everywhere within the 1.2 base code (eg. chan_zap, chan_sip, chan_iax2, pbx_dundi, etc). There are a lot of applications out there (not just easily modifiable dialplans) that make use of the DB calls (custom add on code, XML phone applications, etc). So putting a translation layer so that ast_db_* API calls either go the normal route or translate to func_odbc (or another path) would improve functionality because both old and new apps would be able to seamlessly take advantage of the new database backend or keep using DB1 (the * admin would decide). I haven't looked at the 1.4/1.6 source code yet but I was wondering how many people would benefit from this. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] replace astdb with a cluster-capable sql database engine
Hi! So putting a translation layer so that ast_db_* API calls either go the normal route or translate to func_odbc (or another path) would improve functionality because both old and new apps would be able to seamlessly take advantage of the new database backend or keep using DB1 (the * admin would decide). This is not exactly what you are aiming at, and probably outdated, but still close enough to be of interest, I assume: http://www.voip-info.org/wiki/view/Asterisk+app_dbodbc Cheers, Philipp ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] replace astdb with a cluster-capable sql database engine
--- Bruce Reeves [EMAIL PROTECTED] wrote: Vieri, What values are you looking to move from astdb? I have used realtime to store values for call features and other functions in the dial plan. I'm curious what you are looking to do. Thanks for the feedback Bruce. What I'm trying to do is fairly simple. I have two asterisk boxes on one site which are practically identical. They have the same dialplan and serve the same pool of SIP extensions. They are configured as to load balance SIP registrations, ie. aprox. 50% register on pbx1 and 50% on pbx2. For now I'm hardcoding each client where they should register but will soon adopt another mechanism such as DNS SRV or Linux-HA or something. Whenever a SIP user wants to contact another extension, asterisk uses DUNDi with regcontext to check where to place the call. For now it's just a two-server setup so I could very well make use of IAX2 friend trunks but if I start using more than 2 servers then DUNDi lookups will be more efficient. The only telephony hardware I have on both systems is: 1 E1 PRI card and 1 4-port BRI card. I have 8 ISDN lines so 4 go to each pbx server. I have 2 PRI lines that connect to an Alcatel PBX so each asterisk pbx has 1 PRI connection (routed the same way of course). I wanted to implement some kind of master-master cluster of two servers but not necessarily in the strict sense of a cluster. The setup fits my needs (work in progress): * load balanced sip registrations (about 300 on each server) * sip extensions on one server will call out first on the local BRI and PRI ports and if they are all congested then they will go out to the other server via a IAX friend trunk and try to dial out the other set of BRI/PRI ports. * sip extensions will use (are using) DUNDi with regcontext to establish connections with each other. * incoming calls from PRI/BRI ports will use DUNDi to connect to their SIP destination. So everything seems to be ok except for astdb. Let me give just one simple example. Suppose extension 101 dials *78 which sets DND on (in asterisk) and sets a DB key value on pbx server 1. Then suppose server 1 goes down for some reason and extension 101 auto-registers on server 2. If someone calls 101 then the phone will start to ring but should report BUSY. This is only an example but there are a lot more because I'm using FreePBX which makes extensive use of DB calls (a hacked up version but it's mainly FreePBX). I am not using Realtime but if someone can tell me that the astdb problem will go away with Realtime then I can give it a try. Even the main FreePBX developer would be interested to know if the future holds the chance of having a different astdb backend so that rewriting of the complex dialplan is not necessary. So, if the astdb backend were a modern SQL database engine like MySQL or Postgresql then I could easily setup a master-master cluster which would solve the DND example I described earlier. I noticed that it's not the first time people bring this issue up but I've never seen a clear resolution. It seems as if people don't actually care to have the choice of another backend for astdb so I suppose they are getting away with it somehow (maybe by using Realtime which I never have). Thanks for the feedback! Vieri Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] replace astdb with a cluster-capable sql database engine
On 3/8/08, Vieri [EMAIL PROTECTED] wrote: I've been searching the Internet for information regarding the replacement of astdb with a modern sql engine. There are several reasons one would like to do this. First of all, external applications have a hard time reading/writing to the now-old astdb format. Also (and this is what interests me most), the sql astdb could easily be clustered throughout several servers (I'm looking for a master-master MySQL 2-server cluster solution). Asterisk has brought up Realtime which is very powerful but, correct me if I'm wrong, it still requires astdb internally. In other words, if I call Set(DB) in the dialplan then it will always be using astdb regardless of realtime. Some projects like Callweaver have forked from Asterisk 1.2 and replaced astdb with sqlite. I'm wondering if Asterisk has plans to allow the user to choose the astdb backend: standard db1, sqlite, MySQL (which I would use with nbcluster for my clustering purposes), Postgresql with Slony-II, PGcluster, etc. Or is it already possible? There has been some talk on this before: http://lists.digium.com/pipermail/asterisk-dev/2004-December/007846.html Also, the func_odbc feature seems to be very powerful: http://www.asteriskpbx.org/func_odbc but: 1) would there be potential issues with db handles on a very busy asterisk system after a relatively long run time? 2) would there be a way to map the odbc function(s) to the DB functions (Set(DB), read and write, DBdel, etc) so that rewriting the whole dialplan would not be necessary? (that's the whole point of defining a different astdb backend) If there are known problems/issues/projects/alternatives then please let me know. There are really not much dependencies in asterisk to AstDB. As i recall - some SIP registration data is stored in AstDB, and persistent queue members (but you can replace that with Realtime queue members). For your own custom data you can use Realtime engine - it has INSERT and DELETE support in 1.6, and it's easily backportable to 1.4 (if you're interested i can give you working patches). All you have to do is declare realtime class in extconfig.conf, and then use Set(REALTIME()=...). For more info on this see http://www.voip-info.org/wiki/index.php?page=Asterisk+func+realtime Also there's a mysql command in asterisk-addons, but you have keep track of connections - connect and disconnect in dialplan. Or there's odbc module that creates permanent connection, and allows you to declare SQL functions with replacable variables, but personally i don't like having additional layer. For this you can search mailinglist, it's been described numerous times. Regards, Atis -- Atis Lezdins, VoIP Project Manager / Developer, [EMAIL PROTECTED] Skype: atis.lezdins Cell Phone: +371 28806004 Cell Phone: +1 800 7300689 Work phone: +1 800 7502835 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] replace astdb with a cluster-capable sql database engine
On Sun, Mar 09, 2008 at 01:16:39AM -0800, Vieri wrote: Let me give just one simple example. Suppose extension 101 dials *78 which sets DND on (in asterisk) and sets a DB key value on pbx server 1. Then suppose server 1 goes down for some reason and extension 101 auto-registers on server 2. If someone calls 101 then the phone will start to ring but should report BUSY. I'm not sure that there's a good reason to use the built-in chan_zap feature and not implement your own through the dialplan. If you have the extension '*78' it will override the built-in Zaptel one. -- Tzafrir Cohen icq#16849755 jabber:[EMAIL PROTECTED] +972-50-7952406 mailto:[EMAIL PROTECTED] http://www.xorcom.com iax:[EMAIL PROTECTED]/tzafrir ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] replace astdb with a cluster-capable sql database engine (was: Re: asterisk-users Digest, Vol 44, Issue 22)
unix-odbc with Asterisk Realtime is one good way to use a different backend DB than MySQL. I haven't heard of bit rot problems running it over long times, but I'd like to if there are any. I'm particularly interested in seeing reports of Asterisk Realtime backed by Postgres. The problem with pointing dialplan DB functions like Set(DB) at unix-odbc (or any relational driver) is that the native functions use the very fast BDB, not a relational one, that has very different (better) scaling profiles than running those calls over a database driver, especially across a network. Having all those BDB data available in the relational DB for joins and other integrated queries (and backup and other RDBMS features) would be great, but there is danger in switching from the simple and high performance BDB into a more complex RDBMS. One way to do it is to leave the native BDB system, but interface a replica in the RDBMS to it. A polling process that replicates the BDB data into the RDBMS, and (if not negligible) updates the RDBMS with a read whenever the RDBMS copy is used (and then writes to the BDB when the RDBMS replica changes) would let the BDB remain as a fast/reliable cache directly to Asterisk, but use its data properly in the RDBMS. I'm interested in seeing any work performed on integrating Asterisk's data tier away from its defaults. Especially when that work is making Postgres the authoritive data store. I have various info that can help such a project, if people are really working on it. On Sat, 2008-03-08 at 20:08 -0600, [EMAIL PROTECTED] wrote: Date: Sat, 8 Mar 2008 10:01:28 -0800 (PST) From: Vieri [EMAIL PROTECTED] Subject: [asterisk-users] replace astdb with a cluster-capable sql databaseengine To: asterisk-users@lists.digium.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 I've been searching the Internet for information regarding the replacement of astdb with a modern sql engine. There are several reasons one would like to do this. First of all, external applications have a hard time reading/writing to the now-old astdb format. Also (and this is what interests me most), the sql astdb could easily be clustered throughout several servers (I'm looking for a master-master MySQL 2-server cluster solution). Asterisk has brought up Realtime which is very powerful but, correct me if I'm wrong, it still requires astdb internally. In other words, if I call Set(DB) in the dialplan then it will always be using astdb regardless of realtime. Some projects like Callweaver have forked from Asterisk 1.2 and replaced astdb with sqlite. I'm wondering if Asterisk has plans to allow the user to choose the astdb backend: standard db1, sqlite, MySQL (which I would use with nbcluster for my clustering purposes), Postgresql with Slony-II, PGcluster, etc. Or is it already possible? There has been some talk on this before: http://lists.digium.com/pipermail/asterisk-dev/2004-December/007846.html Also, the func_odbc feature seems to be very powerful: http://www.asteriskpbx.org/func_odbc but: 1) would there be potential issues with db handles on a very busy asterisk system after a relatively long run time? 2) would there be a way to map the odbc function(s) to the DB functions (Set(DB), read and write, DBdel, etc) so that rewriting the whole dialplan would not be necessary? (that's the whole point of defining a different astdb backend) If there are known problems/issues/projects/alternatives then please let me know. Thanks -- (C) Matthew Rubenstein ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] replace astdb with a cluster-capable sql database engine
--- Atis Lezdins [EMAIL PROTECTED] wrote: For your own custom data you can use Realtime engine - it has INSERT and DELETE support in 1.6, and it's easily backportable to 1.4 (if you're interested i can give you working patches). All you have to do is declare realtime class in extconfig.conf, and then use Set(REALTIME()=...). Interesting but I'm not ready for 1.6 and I don't know if I want to patch 1.4 yet. Apart from INSERT and DELETE I guess it can also UPDATE/REPLACE. Will keep that in mind when I finally upgrade from 1.2. Also there's a mysql command in asterisk-addons, but you have keep track of connections - connect and disconnect in dialplan. Right. Or there's odbc module that creates permanent connection, and allows you to declare SQL functions with replacable variables, but personally i don't like having additional layer. For this you can search mailinglist, it's been described numerous times. So if I use func_odbc (there's an official backport for 1.2) I won't run into the db handle leaks as there's a permanent connection? Thanks Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] replace astdb with a cluster-capable sql database engine
On Sunday 09 March 2008 12:26:55 Vieri wrote: --- Atis Lezdins [EMAIL PROTECTED] wrote: Or there's odbc module that creates permanent connection, and allows you to declare SQL functions with replacable variables, but personally i don't like having additional layer. For this you can search mailinglist, it's been described numerous times. So if I use func_odbc (there's an official backport for 1.2) I won't run into the db handle leaks as there's a permanent connection? I wouldn't say it's official; it's simply a version previously maintained by me, the author of the module. It's quickly moving towards unmaintained status (I haven't touched it in 6 months, and I may never again). Also note that there are some features in the 1.2 backport which are not in the 1.4 tree; it's a backport from trunk. However, there is likewise a backport of the trunk features for 1.4. You should never run into database handle leaks with func_odbc, no. The connections are handled transparently and released when necessary. -- Tilghman ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] replace astdb with a cluster-capable sql database engine
To be perfectly honest, the REALTIME function is absolutely hideous when it comes to reading data from the RealTime database. What on earth the Asterisk developers were thinking when they replaced the perfectly usable RealTime (which sets a channel variable for each field in the database) with the REALTIME function that requires massive amounts of additional code to get /any/ useful information out of it, I have no idea. How replacing one application that can give you a phone's IP address in a channel variable with a function that requires a dozen or more lines of code to achieve the same end result can be considered an improvement, I have no idea. If the REALTIME function would allow you to specify a single field to retrieve, then yes, it would be an improvement. Because it doesn't, it looks to be damn near unusable. Atis Lezdins wrote: For your own custom data you can use Realtime engine - it has INSERT and DELETE support in 1.6, and it's easily backportable to 1.4 (if you're interested i can give you working patches). All you have to do is declare realtime class in extconfig.conf, and then use Set(REALTIME()=...). For more info on this see http://www.voip-info.org/wiki/index.php?page=Asterisk+func+realtime ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] replace astdb with a cluster-capable sql database engine
Would it be possible to modify the API calls that are currently going to the AstDB code within Asterisk, and put a translation layer to have them use the func_odbc instead (or either one)? I came across some old code of an odbc version of app_db which I suppose is obsolete. http://www.voip-info.org/wiki/view/Asterisk+app_dbodbc http://downloads.netmonks.ca/app_dbodbc.c At a lower level, for everything Asterisk does to its AstDB, maybe there could be a system setting which allows the user to say, ok, use DB, or, no, use func_odbc (not at the dialplan level). Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] replace astdb with a cluster-capable sql database engine
I've been searching the Internet for information regarding the replacement of astdb with a modern sql engine. There are several reasons one would like to do this. First of all, external applications have a hard time reading/writing to the now-old astdb format. Also (and this is what interests me most), the sql astdb could easily be clustered throughout several servers (I'm looking for a master-master MySQL 2-server cluster solution). Asterisk has brought up Realtime which is very powerful but, correct me if I'm wrong, it still requires astdb internally. In other words, if I call Set(DB) in the dialplan then it will always be using astdb regardless of realtime. Some projects like Callweaver have forked from Asterisk 1.2 and replaced astdb with sqlite. I'm wondering if Asterisk has plans to allow the user to choose the astdb backend: standard db1, sqlite, MySQL (which I would use with nbcluster for my clustering purposes), Postgresql with Slony-II, PGcluster, etc. Or is it already possible? There has been some talk on this before: http://lists.digium.com/pipermail/asterisk-dev/2004-December/007846.html Also, the func_odbc feature seems to be very powerful: http://www.asteriskpbx.org/func_odbc but: 1) would there be potential issues with db handles on a very busy asterisk system after a relatively long run time? 2) would there be a way to map the odbc function(s) to the DB functions (Set(DB), read and write, DBdel, etc) so that rewriting the whole dialplan would not be necessary? (that's the whole point of defining a different astdb backend) If there are known problems/issues/projects/alternatives then please let me know. Thanks Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] replace astdb with a cluster-capable sql database engine
Vieri, What values are you looking to move from astdb? I have used realtime to store values for call features and other functions in the dial plan. I'm curious what you are looking to do. On Sat, Mar 8, 2008 at 12:01 PM, Vieri [EMAIL PROTECTED] wrote: I've been searching the Internet for information regarding the replacement of astdb with a modern sql engine. There are several reasons one would like to do this. First of all, external applications have a hard time reading/writing to the now-old astdb format. Also (and this is what interests me most), the sql astdb could easily be clustered throughout several servers (I'm looking for a master-master MySQL 2-server cluster solution). Asterisk has brought up Realtime which is very powerful but, correct me if I'm wrong, it still requires astdb internally. In other words, if I call Set(DB) in the dialplan then it will always be using astdb regardless of realtime. Some projects like Callweaver have forked from Asterisk 1.2 and replaced astdb with sqlite. I'm wondering if Asterisk has plans to allow the user to choose the astdb backend: standard db1, sqlite, MySQL (which I would use with nbcluster for my clustering purposes), Postgresql with Slony-II, PGcluster, etc. Or is it already possible? There has been some talk on this before: http://lists.digium.com/pipermail/asterisk-dev/2004-December/007846.html Also, the func_odbc feature seems to be very powerful: http://www.asteriskpbx.org/func_odbc but: 1) would there be potential issues with db handles on a very busy asterisk system after a relatively long run time? 2) would there be a way to map the odbc function(s) to the DB functions (Set(DB), read and write, DBdel, etc) so that rewriting the whole dialplan would not be necessary? (that's the whole point of defining a different astdb backend) If there are known problems/issues/projects/alternatives then please let me know. Thanks Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- * Bruce Reeves, dCAp EUS Networks Office: 212-624-5943 Web: www.euscorp.com ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
