I just made my first 2 modules for asterisk (The 1st one is depriciated
already).
I was annoyed that i couldn't get GotoIf to take any expressions besides a
boolean
then i made a module to mimic gotoif and parse a few expressions like (${var}
> 12)
exten => 1,1,gotoif_expr,${var} > 12:1|4:1|5
Then I immediatly obseleted it with this new embedded perl module that lets
you implement stuff at will from perl instead of needing to make a module
Say you want to make gotoif that can parse expressions
exten => 1,1,Perl,gotoif:${var} > 12:1|4:1|5
say ${var} = 4
then gotoif perl sub is launched as
gotoif(4,"1|4","1|5");
and gotoif() looks like:
sub gotoif(@) {
my($expr,$goto1,$goto2) = @_;
my $test;
eval "\$test = ($expr)";
my $ret = "goto:" . (($test) ? $goto1 : $goto2);
print "test: [$expr] = [$test] [$ret]\n";
$ret;
}
Funy thing is I was too obcessed with what I had already seen so far in asterisk
that
I didnt even notice AGI until yesterday =)
here is my beta README
app_perl 1.0
This is app_perl the "mod_perl" of sorts for asterisk. It is an
actual live Perl Interpreter
embeded in a module so when it starts up the perl stays resident in memory the
whole life of the
Asterisk process.
FEATURES:
It can call perl functions from extensions.conf in a special package
called Asterisk::Perl.
that is loaded on startup from /etc/asterisk/Asterisk::Perl.pm.
exten => 1,1,Perl,myfunc:arg_1:arg_2:arg_n......
It then does it's business and returns one or more special
directives that
are asterisk related operations processed by the module.
they are returned as a list (array) of scalar each containing a
specially formated
command to feed back into asterisk via the C module.
These are counterparts to the real directives found in extensions.conf
only probably
there is less error checking and more direct control a.k.a. likelyhood
to crash.
Valid commands so far.......
setvar:<name>:<value>
goto:<ext>|<line>
add_ext:<context>:<replace>:<extension>:<priority>:<application>:<data>:<callerid>
runapp:<app>:<data>
include:<new_context>:<existing_context>
ignorepat:<context>:<name>
switch:<context>:<app>:<data>
There are also some special commands: (1 for now)
thread:<function>
This will spin off a thread with the perl sub you specify running inside
it.
the sub will get 1 scalar arg being the number of times it was run
(starting with 1)
you can return an array full of more commands listed above with 1
exception:
if you put the keyword "loop" in the list, it will call the
function again and increment the counter arg.
You can use this to say run 1 thread to listen on a tcp port and
populate a shared data object
and use another to run in a loop and pass the altered data back to
asterisk and relaunch
every 1 min or so. And of core all this stuff can be used to horribly
crash the program.
The function can return as many commands as it wants but of corse
several goto or other such nonsense
may not be too smart.
The functions startup() and shutdown() are called respectively on load
and unload of the module
allowing you to create on the fly contexts and configuration by looking
up data from a database,more files etc.
you can even make the dialing of a certian extension cause a perl func
to create more extensions or to
rewrite the existing one on the fly. Of course, you can't do any
channel related commands (runapp etc)
from the startup function because there is no call in progress so they
get ignored.
BUGS:
If you stare at the source code from about 2 feet back for approx 30
seconds you will start
to see that the entire thing is in itself 1 large bug. I am not a C
programmer but rather
a Perl programmer so that was my motivation for this idea but it
probably is sucky C style etc...
---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20030617/c0fdf104/attachment.htm
Of course you can use Gotoif with expressions.
Gotoif,$[${VAR} > 12]?1|4:1|5
Martin
On Tue, 17 Jun 2003, Anthony Minessale wrote:
>
> I just made my first 2 modules for asterisk (The 1st one is depriciated
already).
>
> I was annoyed that i couldn't get GotoIf to take any expressions
besides a boolean
> then i made a module to mimic gotoif and parse a few expressions like
(${var} > 12)
> exten => 1,1,gotoif_expr,${var} > 12:1|4:1|5
>
> Then I immediatly obseleted it with this new embedded perl module that lets
> you implement stuff at will from perl instead of needing to make a module
>
> Say you want to make gotoif that can parse expressions
>
> exten => 1,1,Perl,gotoif:${var} > 12:1|4:1|5
>
> say ${var} = 4
>
> then gotoif perl sub is launched as
>
> gotoif(4,"1|4","1|5");
>
> and gotoif() looks like:
>
>
> sub gotoif(@) {
> my($expr,$goto1,$goto2) = @_;
> my $test;
> eval "\$test = ($expr)";
> my $ret = "goto:" . (($test) ? $goto1 : $goto2);
> print "test: [$expr] = [$test] [$ret]\n";
> $ret;
> }
>
> Funy thing is I was too obcessed with what I had already seen so far in
asterisk that
> I didnt even notice AGI until yesterday =)
>
> here is my beta README
>
>
>
> app_perl 1.0
>
>
> This is app_perl the "mod_perl" of sorts for asterisk. It is an
actual live Perl Interpreter
> embeded in a module so when it starts up the perl stays resident in memory
the whole life of the
> Asterisk process.
>
> FEATURES:
>
> It can call perl functions from extensions.conf in a special
package called Asterisk::Perl.
> that is loaded on startup from /etc/asterisk/Asterisk::Perl.pm.
>
> exten => 1,1,Perl,myfunc:arg_1:arg_2:arg_n......
>
> It then does it's business and returns one or more special
directives that
> are asterisk related operations processed by the module.
> they are returned as a list (array) of scalar each containing a
specially formated
> command to feed back into asterisk via the C module.
>
> These are counterparts to the real directives found in
extensions.conf only probably
> there is less error checking and more direct control a.k.a.
likelyhood to crash.
>
>
> Valid commands so far.......
>
> setvar:<name>:<value>
> goto:<ext>|<line>
>
add_ext:<context>:<replace>:<extension>:<priority>:<application>:<data>:<callerid>
> runapp:<app>:<data>
> include:<new_context>:<existing_context>
> ignorepat:<context>:<name>
> switch:<context>:<app>:<data>
>
>
> There are also some special commands: (1 for now)
>
> thread:<function>
> This will spin off a thread with the perl sub you specify running
inside it.
> the sub will get 1 scalar arg being the number of times it was run
(starting with 1)
> you can return an array full of more commands listed above with 1
exception:
> if you put the keyword "loop" in the list, it will call
the function again and increment the counter arg.
> You can use this to say run 1 thread to listen on a tcp port and
populate a shared data object
> and use another to run in a loop and pass the altered data back to
asterisk and relaunch
> every 1 min or so. And of core all this stuff can be used to
horribly crash the program.
>
> The function can return as many commands as it wants but of corse
several goto or other such nonsense
> may not be too smart.
>
>
> The functions startup() and shutdown() are called respectively on
load and unload of the module
> allowing you to create on the fly contexts and configuration by
looking up data from a database,more files etc.
> you can even make the dialing of a certian extension cause a perl
func to create more extensions or to
> rewrite the existing one on the fly. Of course, you can't do
any channel related commands (runapp etc)
> from the startup function because there is no call in progress so
they get ignored.
>
>
> BUGS:
>
> If you stare at the source code from about 2 feet back for approx
30 seconds you will start
> to see that the entire thing is in itself 1 large bug. I am not a
C programmer but rather
> a Perl programmer so that was my motivation for this idea but it
probably is sucky C style etc...
>
>
>
>
>
>
>
> ---------------------------------
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
On Tuesday 17 June 2003 10:22, Anthony Minessale wrote:> I just made my first 2 modules for asterisk (The 1st one is > depriciated already). > > I was annoyed that i couldn't get GotoIf to take any expressions > besides a boolean then i made a module to mimic gotoif and parse a > few expressions like (${var} > 12) exten => 1,1,gotoif_expr,${var} > > 12:1|4:1|5You forgot to read README.variables, didn't you? GotoIf($[${var} > 12]?1|4:1|5) -Tilghman
ok forget it .... I was telling a story of what inspired me to write this module that embeds a perl interpreter into the asterisk process and to see if anyone was interested in it (IT'S AN EXPERIMENT) What I get are several replies telling me to RTFM and I would no longer need to solve the problem that inspired my original idea. Does it matter if my original problem could be resolved by RTFM or not?. I'm glad I did'nt't or I would never have gotten the Idea since the end-result is barely related to that problem. Testing expressions in variables is not even the reason to use the module the module allows you to run perl code from within and perform a whole bunch of tasks using perl (RTFM) The example I put in the README just happens to show how to perform an eval on an expression using the new perl functionality the module implements I could just as easily show an example how to connect to a database on startup and create extensions on the fly or how to make a web server that runs inside asterisk (If any of these already are possible sorry again for being inventive or for wanting to do it in perl whichever you want to hang me for.) Sheesh Please don't bother to further discern what I did and did not read or to look for a typo and flame me for it. This list gets enough traffic as it is and there is no need to waste bandwidth to tell me I don't totally know how to work asterisk cos I already know I'm simply playing with it. I only have 2 weeks total experience with asterisk so I can tell you in advance I have a ton of docs to read. I just thought I'd share my findings so far since I was under the impression this was a forum. sorry...... --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20030617/0b41b4be/attachment.htm
ok, I'm not opposed to finding other ways to do the same thing. I got the impression my opening comments explaining how the apple fell on my head may have been the only part anyone took notice of while skimming over all these articles so I'll chill and assume it's not flaming =) Here is a copy of the first release (comments appreciated) http://asterisk.650dialup.com --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20030617/46e41446/attachment.htm
That is probably possible and not too difficult.
I learned what AGI was about 30 minutes after I was finished
with the last revision of app_perl where I added support to
launch a perl function in a thread
(BTW I am suspicious that you
may ironically need perl with no threads compiled for it to work right
in asterisk despite the fact that you gain thread functionality via asterisk)
I have not really carefully looked at AGI yet but from what I remember
It communicates with the ext process via STDIN and looks at the ENV
for information. so what I think you would need would be a fake ENV and a
special variable to contain the same info that would have been sent to STDIN
created uniquely for each execution. This of course would be limiting the AGI
to perl code so another method would be to make
a function via the app_perl or a dedicated C module to run all the agi app
at startup and leave them open speaking back and forth over IO stream.
I do notice I started stepping on the toes of AGI because I never heard of
it while I was coding my module so I think some of the things that AGI does can
also be accomplished on app_perl
The 3 things I was dreaming of when I was working on it were:
1) If the module has the power to create extensions then you can use
it to fetch that data from a database on startup or in mid run.
2) If the module can run threads It could implement
an external listener of some sort and communicate with
a partner thread over shared memory and with the world
over sockets, tcpip etc (web server) I had a demo working
where you could go to the asterisk on a web browser an see
a readout like "number is 0" then if you dial into a certain ext
with a phone the number increments and when you reload the
web page it said "number is 1" and so on.
3) Despite the fact that anything I can possibly dream up
can be implemented with ease because of the robustness
of asterisk (adding plug ins is like doing a child's jigsaw puzzle
as you can see because I don't even know how to work it yet can
build a module for it)
By integrating perl I felt more of those ideas could be brought to life
faster (1 module can open several doors) and It would allow me
to bridge the gap between asterisk and a ton of perl stuff I have
made along the years.
---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20030623/65ba72b6/attachment.htm
No point in reinventing the wheel here. PersistentPerl (aka SpeedyCGI) can eliminate the startup cost for using perl with AGIs. It works great, and even allows the processes to reuse database connections James On Mon, 23 Jun 2003, Anthony Minessale wrote:> That is probably possible and not too difficult. > > I learned what AGI was about 30 minutes after I was finished > with the last revision of app_perl where I added support to > launch a perl function in a thread > > (BTW I am suspicious that you > may ironically need perl with no threads compiled for it to work right > in asterisk despite the fact that you gain thread functionality via asterisk) > > I have not really carefully looked at AGI yet but from what I remember > It communicates with the ext process via STDIN and looks at the ENV > for information. so what I think you would need would be a fake ENV and a special variable to contain the same info that would have been sent to STDIN created uniquely for each execution. This of course would be limiting the AGI to perl code so another method would be to make > a function via the app_perl or a dedicated C module to run all the agi app > at startup and leave them open speaking back and forth over IO stream. > > I do notice I started stepping on the toes of AGI because I never heard of > it while I was coding my module so I think some of the things that AGI does can also be accomplished on app_perl > > > The 3 things I was dreaming of when I was working on it were: > > 1) If the module has the power to create extensions then you can use > it to fetch that data from a database on startup or in mid run. > > > 2) If the module can run threads It could implement > an external listener of some sort and communicate with > a partner thread over shared memory and with the world > over sockets, tcpip etc (web server) I had a demo working > where you could go to the asterisk on a web browser an see > a readout like "number is 0" then if you dial into a certain ext > with a phone the number increments and when you reload the > web page it said "number is 1" and so on. > >
Would anyone be so kind as to explain why no voice is heard through the phone when calling? Thanks. On Mon, 2003-06-23 at 10:34, James Golovich wrote:> No point in reinventing the wheel here. PersistentPerl (aka SpeedyCGI) > can eliminate the startup cost for using perl with AGIs. > > It works great, and even allows the processes to reuse database > connections > > James > > > On Mon, 23 Jun 2003, Anthony Minessale wrote: > > > That is probably possible and not too difficult. > > > > I learned what AGI was about 30 minutes after I was finished > > with the last revision of app_perl where I added support to > > launch a perl function in a thread > > > > (BTW I am suspicious that you > > may ironically need perl with no threads compiled for it to work right > > in asterisk despite the fact that you gain thread functionality via asterisk) > > > > I have not really carefully looked at AGI yet but from what I remember > > It communicates with the ext process via STDIN and looks at the ENV > > for information. so what I think you would need would be a fake ENV and a special variable to contain the same info that would have been sent to STDIN created uniquely for each execution. This of course would be limiting the AGI to perl code so another method would be to make > > a function via the app_perl or a dedicated C module to run all the agi app > > at startup and leave them open speaking back and forth over IO stream. > > > > I do notice I started stepping on the toes of AGI because I never heard of > > it while I was coding my module so I think some of the things that AGI does can also be accomplished on app_perl > > > > > > The 3 things I was dreaming of when I was working on it were: > > > > 1) If the module has the power to create extensions then you can use > > it to fetch that data from a database on startup or in mid run. > > > > > > 2) If the module can run threads It could implement > > an external listener of some sort and communicate with > > a partner thread over shared memory and with the world > > over sockets, tcpip etc (web server) I had a demo working > > where you could go to the asterisk on a web browser an see > > a readout like "number is 0" then if you dial into a certain ext > > with a phone the number increments and when you reload the > > web page it said "number is 1" and so on. > > > > > > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users-- Jordan In a world without windows, who needs gates?
On Monday, Jun 23, 2003, at 10:34 America/Los_Angeles, James Golovich wrote:> No point in reinventing the wheel here. PersistentPerl (aka SpeedyCGI) > can eliminate the startup cost for using perl with AGIs. > > It works great, and even allows the processes to reuse database > connectionsSpeed is not the only reason to embed Perl in the "host application". The real cool stuff comes if the API of the host application is exposed to Perl, so you can write asterisk modules in Perl (like you can use the Apache API from Perl with mod_perl). - ask -- http://www.askbjoernhansen.com/
The first wheel was said to be a log, then probably 2 logs today it is rubber , metal , wooden etc. J.K. I'm sure debate over reinventing the wheel or if perl sucks or not will see more airtime than the topic of using perl in asterisk being cool or not will. Everything I needed in the app_perl was located right in pbx.c from aterisk so I actually include that c file into mine out of fear of losing compatibility since it evolves so fast. What I do now is by includeing pbx.c I can call any of the important func that asterisk itself uses so I re-implement my own mini-command interepter for the return value of a perl fucntion to send to me then I parse those commands and feed them to real asterisk calls. So for a start all the func i frontend in app_perl could be perlified with xs and buried in the module as a package so the per func could use it and call those functions. So you get C embedding perl embedding C to call func from the original C Sounds Silly but you could avoid inventing large painful wheels in C by hooking up perl and its army of premade wheels (I made < 1k webserver func to load in asterisk already) Lot's of possibilities........ perl likes to parse text more than anything else you could develop the config file parsing engine that way and go to town making up a format rather than dealing with coding the parsing and you can teach asterisk to read config files from different systems etc. maybe asterisk is the emacs of pbx systems (oh oh here come more flames going off on a tangent) YES I like PERL! and EMACS! On Monday, Jun 23, 2003, at 10:34 America/Los_Angeles, James Golovich wrote:> No point in reinventing the wheel here. PersistentPerl (akaSpeedyCGI)> can eliminate the startup cost for using perl with AGIs. > > It works great, and even allows the processes to reuse database > connectionsSpeed is not the only reason to embed Perl in the "host application". The real cool stuff comes if the API of the host application is exposed to Perl, so you can write asterisk modules in Perl (like you can use the Apache API from Perl with mod_perl). - ask -- http://www.askbjoernhansen.com/ --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20030625/978027bd/attachment.htm
Oops, every time I make up a random arbitrary example someone pounces on it. =p (BTW I am happy with the config file, I was just making up an example) Hmmm embedding Perl in asterisk will allow us to <RANDOM_IDEA> REPLY: <RANDOM_IDEA> is choose 1: REDUNDANT USELESS STUPID FAT RESOURCE INTENSIVE UGLY Perl is a REDUNDANT USELESS STUPID UGLY FAT RESOURCE INTENSIVE hog that can or can not be embedded into C applications depending on the choice , preference or need of the maintainer. I have cross compiled apache to run on an IPAQ with hardly any modules in it It is a tiny binary (psst I still have Perl on my IPAQ too) That doesn't mean apache shod not have mod_Perl as an option cos it bloats it. I have another apache that is huge with a handful of modules compiled into it For me, being able to use a PC as a PBX is close enough as having linksys type phone router. (BTW As soon as they make one everybody will hack it and use it as a PC) I tossed together a p4 2.4GHZ 120GB HD 500M ram box to test stuff on. and It was like $500 bux w/o even trying to be thrifty (6 PCI),(ONBOARD 10/100 LAN,VID) filled with 4 analog line cards and a 4 Line TD400M Id rather have that than a linksys-type-thing where everyone's free stuff is arranged in a cheap plastic box and put on sale. But if one was to exist it would probably have huge storage in it for voice mail and could spare the room for little ol' Perl If the inventor permitted. Maybe we can make etherboot or CDROM asterisk initrd image so you can have diskless $200 PC become an instant asterisk box with no moving parts Maybe we can port mini-asterisk to run right in the phone as it's OS. See, this ranting I like to do is called brainstorming It's not mandatory to act on every idea but perhaps speaking them aloud or posting them to forums will lead to a good idea every once in a while. From: Steven Critchfield <critch@basesys.com> Ahh, now we can understand your ailment ;) It has been brought up before, and I forgot to mention it in the TCL config debate, but the configs need to be small and able to not become bloated. We have developers here trying to put asterisk on embedded systems so that one day we might go to the store and buy a linksys router like phone switch for our home. Embedding Perl into a core function like config means they must allocate resources such as storage for what all Perl brings along with it. So a proposal for those who keep insisting on a separate config formats, What we might need is a directive that can be placed in the general section of the extension.conf file that acts like a extension, but is executed on start and reload. From there a system call could be generated or agi to set up the rest of the system. This makes an easy config method for those experimenting with new formats without cluttering the rest of the code base, or causing undue headache on our embedded friends. --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20030625/a3de0f7b/attachment.htm
Of course engaging brainstorming is not a bad thing but engaging an arbitrary example about config files might be since it is arbitrary =) I just need to be more careful because I think originally I was replying to someone's comments about making perl equivs of all the api calls so the app_perl can make entire modules by itself. I was describing the current features thus far and mentioned you could already create your own config file parser as a random example which then took all the attention. Here's a new one ... Is there already an app to collect digits into a VAR cos if so you could make an ext that collects a numeric login and pass then pass that to app_perl who could auth that info on a db or file and enable/disable extensions since it has the power to create ext and include contexts. On Wed, 2003-06-25 at 18:17, Anthony Minessale wrote:> Oops, every time I make up a random arbitrary example someone > pounces on it. =p >> See, this ranting I like to do is called brainstorming It's not > mandatory to act on > every idea but perhaps speaking them aloud or posting them to forums > will lead to a good idea every once in a while.And not every time someone engages your brainstorming is about shooting down the idea you have. It is about refining it till it doesn't have any good arguments against it. -- Steven Critchfield <critch@basesys.com> --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20030626/acdc4579/attachment.htm