Re: [Asterisk-java-users] Re: DefaultAGIServer bind exception

[Stefan R. <sr...@re...>]

Hi Paul,

sorry for my late reply.

> Thanks for your reply. I think you have a good point about just using 
> two separate servers. I am actually planning on using multiple  servers
> as well, but thought it might be useful to also have two  instances of
> my app running on each server too. Sort of double-load  balancing.

actually with regard to the Asterisk integration it doesnt matter if you
are running two instances on different ports on one machine or two
instances on the same port on different machines. I think its better to
always use all your resources. Maybe thats based on personal experience
with "cold-standby" instances that refuse work right in the second when
you need them.

> Part
> of the complexity is that the app uses both the  Manager and AGI, but I
> use a database to queue up calls to be placed  at specific times. This
> makes things a little trickier, as I need a  "cluster coordinator" to
> ensure that only one process is reading from  the database queue at a
> time. Once calls are pulled from the DB, I  use a JMS queue to
> disseminate calls to multiple instances of my app,  which then initiate
> calls via the Manager interface. Right now, I  pass an asterisk variable
> along with an Origination action,  specifying the hostname of the
> calling application, so that messages  can be easily sent back to the
> same server via AGI (I specify a  variable name for the hostname in the
> dial plan to get this to work  -- this is the same variable passed in
> via the Manager, in the  Origination action). This I think is where
> things get a bit messy,  since my design always tries to pass info back
> to the same server  (i.e. between Manager and AGI). 
[...]
> So my question, is what do you think of this type of design? Is there
> a better approach that might still make configuration easier?

I don't think this design is not that bad at all. If you define one node
of your system to include a JMS consumer, a Manager connection to
Asterisk and an AGI-Server that will work quite well. You dont even need
a variable for the originate but could directly originate to the
associated AGI Server like this:
originateAction.setApplication("AGI");
originateAction.setData("agi://" + hostname + ":" + port +
"/script.agi?callId=" + callId);

The challenge with this kind of setup is to make sure that a node either
is fully available or completely down. That is that there are no nodes
that accept JMS messages but cant originate calls or that can originate
calls but cant answer them via AGI.

The big advantage is that it scales indefinitly.

> What  are
> you doing in your dialplan to create the logic to try a different 
> server if one doesn't respond?

I usually set a variable in my AGI scripts that indicates success and
verifiy in the dialplan that this variable is set to the expected value.
If it is not I know that the AGI didnt run and try the next AGIServer.

> I also had an idea to listen to Registration events, in case an 
> asterisk server wasn't able to successfully register (or lost 
> connection) with a gateway. That way, in case of a failure, I could 
> pull the relevant apps out of the cluster, so that they didn't  receive
> calling commands via JMS (since calls wouldn't be able to be 
> successfully initiated). A successful Registration event could then 
> cause an app to rejoin the cluster in order to start responding to  call
> requests.

yep thats probably a task that each node can do for itself and just
leave the JMS queue in case of trouble (and maybe rejoin later).
you will also benefit from a central coordinator for monitoring. You
might want to check that there is a feedback about a call processed in
response to a JMS message within a certain timeframe and otherwise
exclude the responsible node.

> Anyway, I just thought I'd share my design to see what you thought of 
> our approach, and whether you had any suggestions or caveats.

Thanks a lot! I think its very important to share and discuss some
general design and deployment ideas as there are really plenty of
options regarding Asterisk-Java's usage.

> As far as CCXML, there is an open-source Java-based parser out there 
> already, and from a cursory examination of the code, looks like a 
> decent start, although I don't think it is complete. I believe it  uses
> Rhino for javascript integration. Anyway, you can learn more at:
> 
> http://sourceforge.net/projects/ccxml4j
> 
> The java source is only in CVS, and it looks a bit abandoned, but 
> nevertheless, it's a start.

Ok i'll have a look at it later this week.

> Thanks again for all your help and feedback. And please let me know  if
> you think it would be worthwhile to create a CCXML/asterisk-Java 
> project. 

I will give you some feedback soon.

> I'd definitely be willing to give it a shot, if you thought  it
> might be useful. And if you need any help with anything else  related to
> Asterisk-Java, please let me know -- I'd be happy to help  out in any
> way I can.

Thanks, thats great.
Another item on my Asterisk-Java todo list is finishing the
AsteriskManager.java interface. It should be as easy to use as possible
and free the developer from diving into the Actions, Responses and
Events. You can already see some of the initial work in the current
code, but there is much work left - especially designing a
developer-friendly interface ;)

=Stefan