Re: [Asterisk-Dev] Asterisk channel variable access: a proposal
On Wednesday 18 August 2004 14:32, Tilghman Lesher wrote: On Tuesday 17 August 2004 08:46, John Todd wrote: I hadn't really considered actually making it a filesystem in exactly the same way /proc worked; I just wanted to lay out the structure with the / as the inter-field designator, but keep the data inside astdb (or a shim in front of astdb.) However, I suppose asterisk -rx database get channels/SIP/2109-996a codec-in would work for you to allow external programs to access that data in a hypothetical example. Ack. No. Please. Don't put transient call-related information into astdb (or even in front of it, using a shim). Astdb is for information that you want to remain across calls and across invocations of Asterisk. It is _NOT_ for information which is call-specific. That's why we have channel variables. Note that I have no problem with the information being available in that format, just with the idea of placing it within the database (or making it seem like it comes out of the database). I quoted your entire response as I'm a little lazy and didn't want to cut and paste and attempt to reconstruct what you'd said. :-) What are your feelings on a /proc-style filesystem for asterisk live data? That's precisely what /proc is like under Linux and it seems to make a *lot* of sense, at least in a transient data kind of sense. /ast/IAX2/35210/codec /ast/IAX2/35210/peers /ast/IAX2/35210/jitter ... sounds *great* to me. I agree though that it should not hit any kind of real DB... that would hammer your I/O. -A. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Asterisk channel variable access: a proposal
What are your feelings on a /proc-style filesystem for asterisk live data? That's precisely what /proc is like under Linux and it seems to make a *lot* of sense, at least in a transient data kind of sense. As long as its kind of SNMP-like on-demand structure (i.e. data isn't updated in this filesystem when they change, instead, existing variables are mapped into it), so there's no overhead if I choose not to use it. -alex ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Asterisk channel variable access: a proposal
On Wednesday 18 August 2004 13:37, Andrew Kohlsmith wrote: On Wednesday 18 August 2004 14:32, Tilghman Lesher wrote: On Tuesday 17 August 2004 08:46, John Todd wrote: I hadn't really considered actually making it a filesystem in exactly the same way /proc worked; I just wanted to lay out the structure with the / as the inter-field designator, but keep the data inside astdb (or a shim in front of astdb.) However, I suppose asterisk -rx database get channels/SIP/2109-996a codec-in would work for you to allow external programs to access that data in a hypothetical example. Ack. No. Please. Don't put transient call-related information into astdb (or even in front of it, using a shim). Astdb is for information that you want to remain across calls and across invocations of Asterisk. It is _NOT_ for information which is call-specific. That's why we have channel variables. Note that I have no problem with the information being available in that format, just with the idea of placing it within the database (or making it seem like it comes out of the database). I quoted your entire response as I'm a little lazy and didn't want to cut and paste and attempt to reconstruct what you'd said. :-) What are your feelings on a /proc-style filesystem for asterisk live data? That's precisely what /proc is like under Linux and it seems to make a *lot* of sense, at least in a transient data kind of sense. Doesn't sound too bad. I'd be interested in seeing your implementation. I agree though that it should not hit any kind of real DB... that would hammer your I/O. Well, it shouldn't hit the disk, at any rate. My opposition is purely from an API perspective: I don't want transient data conmingled with my semi-permanent data, at least in a way where I can't distinguish the two. It's fine to have the information available, but let's have different APIs for accessing different types of data. -- Tilghman ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] SQL extensions
Is there a concentrated effort to have a SQL driver for extensions.conf ? Right now I have the LERG for some LATAs I'm terminating to loaded in as a flat file and it seems to work okay, but I would like to be able to dynamically add and remove extensions for origination via an outside interface and I haven't figured out a good way to do that other than a PHP/SQL type setup. Is the code at http://svn.asteriskdocs.org/res_data/ast_data/ stable and current? What's the status on this? I am going to code this if it isn't already done but I do not want to duplicate efforts or reinvent the wheel. yours, Matthew Simpson TxLink Communications www.txlink.net/ 972-617-2877 VoIP Origination and Termination ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] International callback service with Asterisk
Yes we did. The ticket shown below is a patch integrating lots of new stuff to the queue app, but is not the first implementation of these features. Our original code implementing the CLI and the manager interface was submitted to Mark Spencer by mid-2003, and its pieces can be found on this patch. For example, you may notice that the original line static int rqm_exec(struct ast_channel *chan, void *data), the main function that implements the cli remove queue member functionality, and its counterpart static int aqm_exec (struct ast_channel *chan, void *data) are left unchanged by this patch. You may have rewritten it, but the original creation is ours. On Wednesday 18 August 2004 11:20, Paulo Mannheimer wrote: Sorry about that as well. We at Instant Solutions have developed it entirely. Actually these commands were developed so we could dinamically open a manager section from a remote station, where an agent was loggin in, and insert/remove a new queue member. Our contact-center oriented softphone - IVPhone - uses it extensively. Sorry, no, you didn't: http://bugs.digium.com/bug_view_page.php?bug_id=0002125 -- Tilghman ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] MacOS v10.3.5 Compile Problem
Glenn wrote: I am unable to compile asterisk-1.0-RC2 on MacOS v10.3.5: GNU Bison version 1.28 You need a more recent version of Bison (recommended is 1.75). See the Wiki for info how to upgrade ... http://www.voip-info.org/tiki-index.php?page=Asterisk+MacOSX+Support If you have any trouble building bison yourself, mail me off-list and I will send you a pre-built bison 1.75 executable for OSX. rgds benjk PS: Questions related to building Asterisk should be asked on the Asterisk Users' list, not on the Developers' list. -- Sunrise Telephone Systems Ltd 9F Shibuya Daikyo Bldg., 1-13-5 Shibuya, Shibuya-ku, Tokyo, Japan __ GANBARE! NIPPON! Yahoo! JAPAN JOC OFFICIAL INTERNET PORTAL SITE http://mail.ganbare-nippon.yahoo.co.jp/ ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Asterisk channel variable access: a proposal
At 3:12 PM -0500 on 8/18/04, Tilghman Lesher wrote: On Wednesday 18 August 2004 13:37, Andrew Kohlsmith wrote: On Wednesday 18 August 2004 14:32, Tilghman Lesher wrote: On Tuesday 17 August 2004 08:46, John Todd wrote: I hadn't really considered actually making it a filesystem in exactly the same way /proc worked; I just wanted to lay out the structure with the / as the inter-field designator, but keep the data inside astdb (or a shim in front of astdb.) However, I suppose asterisk -rx database get channels/SIP/2109-996a codec-in would work for you to allow external programs to access that data in a hypothetical example. Ack. No. Please. Don't put transient call-related information into astdb (or even in front of it, using a shim). Astdb is for information that you want to remain across calls and across invocations of Asterisk. It is _NOT_ for information which is call-specific. That's why we have channel variables. Note that I have no problem with the information being available in that format, just with the idea of placing it within the database (or making it seem like it comes out of the database). I quoted your entire response as I'm a little lazy and didn't want to cut and paste and attempt to reconstruct what you'd said. :-) What are your feelings on a /proc-style filesystem for asterisk live data? That's precisely what /proc is like under Linux and it seems to make a *lot* of sense, at least in a transient data kind of sense. Doesn't sound too bad. I'd be interested in seeing your implementation. I agree though that it should not hit any kind of real DB... that would hammer your I/O. Well, it shouldn't hit the disk, at any rate. My opposition is purely from an API perspective: I don't want transient data conmingled with my semi-permanent data, at least in a way where I can't distinguish the two. It's fine to have the information available, but let's have different APIs for accessing different types of data. -- Tilghman My comments earlier about this being a 'database-like' structure were only because the /proc filesystem format resembles astdb, which in turn resembles a (flat) database. I agree that none of this should typically hit a disk, or even exist until requested. I think that we've got the astdb structure already in place for certain core variables, and perhaps it makes sense to just extend this format. Creating a top-level structure like /var or /tmp might be able to allow easy determination between values that get stored across restarts (like /SIP does) and values that don't get stored which are per-call based. This could just be trying to shoehorn things into the wrong structure; I'm just trying to present ideas in an already-understood syntax that we have on-hand. An alternate method would be to create an application, as has been suggested. This may be more modular and require less patches to the mainline code (though that is a poor reason to choose one method over the other - convenience of explanation and patching) The third method would be to completely re-work Asterisk, as has also been suggested. JT ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
