IAX2 Java library (was Re: [Asterisk-Users] New IAX software phone (for WIndows platform))

[Steven Critchfield]

On Mon, 2003-11-03 at 12:02, Alastair Maw wrote:
> On 03/11/03 16:35, Jeremy McNamara wrote:
> 
> >> I'm implementing a Java-based IVR server (and yes, I know Asterisk does
> >> IVR, and no, it's not flexible enough to do what I want and no, it
> >> doesn't integrate well with the Java systems we have, etc. hence my
> >> doing this).
> > 
> > Are you mad?  What is not flexable enough for you? Java knows what STDIN 
> > and STDOUT is, right?  What more do you need?
> 
> Not wanting to start a flamewar, but...

Awww, come on, they are fun, right? (more below that isn't joking
around)

>    - I can't possibly fork a whole JVM process for each caller. It's much
>      too inefficient. This needs to support hundreds of simultaneous
>      calls, and the GNU Java compiler just isn't good enough for our
>      needs. I guess I could write an AGI wrapper script which connected
>      to the Java server over a TCP connection or something and piped the
>      stdin/out down the line to it.

Good reason maybe not to support Java, but you are correct in the
potential interface.

>    - We'd like to use Java because:
>      - Need to do RMI to existing systems. Can't be bothered with all
>        the CORBA nonsense.
>      - It's more maintainable within our organization.
>      - We have lots of existing components to support.
>      - It does all the interoperability stuff we need very nicely,
>        so we save time once the system is built (XML, etc.).
>      - We like it. :)

Ohhh, Java weenies stick together. ;) 

>    - I need access to the raw audio streams in realtime for various
>      reasons (need to do DSP stuff for some clients, etc). Can I get this
>      easily with AGI? Along with this, I need to be able to play audio
>      from a URL. I don't want to have to download the whole file from the
>      URL in order to play it - it wants to be streamed. Is this possible
>      with AGI? The docs aren't very good for AGI, so I don't really
>      know...

No, you can not get to this all easily with AGI. AGI currently will play
files on a currently mounted filesystem. Audio can be gotten out of it,
but it is in a strange manner, and is only half of the requirement you
listed. Sounds like you really need a C programmer and get into the guts
of asterisk. Can't get more flexible than having the source code
yourself to do anything you want. You could add your DSP routines into
the dsp.c file and call them when needed. You can also write a asterisk
application and have direct access to all the audio in every direction
just as you want it.

>    - I need to be able to generate large amounts of audio in realtime,
>      conference people together but then only play an audio file to one
>      person within the conference, etc. I don't think AGI is flexible
>      enough to do this.

Meetme is doing the conferencing real well already, maybe needs a little
tweeking to fully meet your needs, but it is a known working bit of
code.

>    - I'd like to be able to move from Asterisk to something else if I
>      need to. This is why originally I was doing things using SIP/RTP.

What else is there worth using??? Are you one of those people who always
develops apps thinking, what if someone buys this and wants to run it on
Oracle? or atleast something to that idea. 

>    - The documentation for AGI is very poor. I know it is for IAX, too,
>      but I can see a Java IAX library being useful for client development
>      too, and I'd like to give a little back to the * community, you
>      know?

Actually they documentation is just programmer oriented. The
documentation is included as example scripts and the section of
apps/app_agi.c that contains a nice description of each function that is
available. You can even do the following from the CLI, "show agi" to
give you a list of agi commands, and "show agi <command>" to get the
paragraph or more of description of what each command does. This is one
of the few parts of asterisk where the documentation actually shines
pretty well.

> There are other reasons, but I haven't the time to explain right now. 
> The above are the most important.
-- 
Steven Critchfield  <critch at basesys.com>