asterisk users - Feb 2007 - Originating calls: Astmanproxy vs Direct Connection vs Call files

I've got around 45 people who need to place calls from our inhouse app. 
What is the considered "best practice" for placing these calls:

1) All clients connect to astmanproxy, and use AMI API Originate command
2) All clients connect directly to the astersik AMI and use the API 
Originate command
3) All clients create a db record, some process reads the record and 
writes out a call file
4) All clients connect to a web / socket service which then writes a 
call file ...

We are currently using #1, but every few days or so, the "putting" of 
data seems to take longer and longer. If I kill astmanproxy and restart 
it, the system is lighting fast for another few days.

What settings would I need for astmanproxy in order simply to access the 
AMI API (I don't need to receive or process events from asterisk)

Julian

On 13 Feb 2007, at 12:56, Julian Lyndon-Smith wrote:
> I've got around 45 people who need to place calls from our inhouse  
> app. What is the considered "best practice" for placing these
calls:
>
> 1) All clients connect to astmanproxy, and use AMI API Originate  
> command
> 2) All clients connect directly to the astersik AMI and use the API  
> Originate command
> 3) All clients create a db record, some process reads the record  
> and writes out a call file
> 4) All clients connect to a web / socket service which then writes  
> a call file ...
I'd advise a variation on 4)

All clients use a (SOAP/XML/http post?) web service.

Web service is implemented as a Java Servlet. Servlet uses the  
(excellent) asterisk-java package
to send commands to AMI

We've done something like it and are pretty happy.


>
> We are currently using #1, but every few days or so, the
"putting"
> of data seems to take longer and longer. If I kill astmanproxy and  
> restart it, the system is lighting fast for another few days.
>
> What settings would I need for astmanproxy in order simply to  
> access the AMI API (I don't need to receive or process events from  
> asterisk)
>
> Julian

Tim Panton

www.mexuar.net
www.westhawk.co.uk/