Asterisk AGI and Java

Bryan Sant bryan.sant at gmail.com
Fri Aug 19 15:56:20 MDT 2005


On 8/19/05, Derek <derek at burdick.cc> wrote:
> been delivered.  Since this is written in Java I do not want it to
> launch the application everytime a call comes in on an extension.  From
> what I have read about AGI is that it communicates over stdin,stdout and
> stderr.  The documents I have read almost make it sound like the script
> or application is launched everytime a new call comes in.

I'm guessing that establishing the CTI connection is expensive and you
don't want to re-establish the connection each time a phone call comes
in.  Modern JVMs start up very quickly -- there may be between a 0.10
to 0.25 second delay in starting Sun's 1.5 JVM.  If reconnecting to
the CTI server doesn't take much time, then you may want to consider
allowing a new java process to be spawned for each call.

In any case, if you want to keep the java program running, I would
suggest writing a wrapper program that can be spawned quickly that
will interface with your long-running java app.  The method of
communication between the two would be named pipes.  Create named
pipes for stdin, stdout, and stderr.  The picture would look like
this:

AGI >>  wrapper >> pipes >> java program.

Say you did:  mkfifo my_stdin; mkfifo my_stdout; mkfifo my_stderr

So your wrapper would write its stdin data to the "my_stdin" pipe. 
Your java app would read in input from that file, process it, and then
write responses out to either "my_stdout" or "my_stderr" pipes.  The
wrapper program would be reading both of the output pipes and would
dump the contents it reads to its proper stdout/stderr.

Once a call transaction is done, your java app would then send some
kind of EOF token to say "my_stderr" and the wapper would intercept
that and quit.  AGI should be happy that processes are spawning and
exiting per transaction, Java is always running with its CTI
connection, and the wrapper just needs to be dumb and forward things
back and forth.

-Bryan



More information about the PLUG mailing list