Asterisk AGI and Java

Derek derek at
Mon Aug 22 09:23:26 MDT 2005

It is reasonably expensive but I need to maintain the connection to 
process other tasks, like a failover to the backup CTI server and other 
maintenance type things.  The CTI server also sends events 
asynchronously to the clients which could possible arrive slightly 
before the call.  If I do not maintain a connection I would then have to 
request the data, which would add even more delay.

It looks like Asterisk-java implements FastAGI, which takes care of the 
wrapper and communication protocol for me which will simplify the design 
and coding times.

Bryan Sant wrote:

>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
>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.
>| This has been a P.L.U.G. mailing. |
>|      Don't Fear the Penguin.      |
>|  IRC: #utah at   |

More information about the PLUG mailing list