asterisk users - Nov 2007 - Billing/Call Control engine : AGI scripts/ AstMan API

Hello ppl,

Have implemented a really nice Billing engine using AGI scripts. So far 
it works fine, tho haven't yet put it in the torture cell.

The AGI scripts have been written in PHP, using MySQL for the billing 
and profile information.
The major disadvantages I see using AGI scripts :
1. A new process(invocation of PHP scripts) on every new call.
2. MySQL connections on every instance of the PHP AGI script. (I am not 
too sure, if connections can be maintained across processes, am no PHP 
guru. I think, if I write in C/C++ can use shared memory for maintaining 
the connection).

So, to overcome these issues, I was thinking of using AstMan APIs along 
with astmanproxy, with the setup being something like this :

Asterisk <---------> astmanproxy <-----------------> Billing 
Engine(control/access)

Has anyone ever tried this?
The one seriously big work with this approach would be to have an FSM 
built into my billing engine, maintaining call states, etc. That seems 
to be quite a daunting task to be done in a short time.

Any ideas anyone?or any similar experiences, in terms of performance, 
scalability, etc. w.r.t both AGI scripts and AstMan API?

TiA
- Benjamin Jacob.






EMAIL DISCLAIMER : This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to whom they are
addressed. Any unauthorised distribution or copying is strictly prohibited. If
you receive this transmission in error, please notify the sender by reply email
and then destroy the message. Opinions, conclusions and other information in
this message that do not relate to official business of Mascon shall be
understood to be neither given nor endorsed by Mascon. Any information contained
in this email, when addressed to Mascon clients is subject to the terms and
conditions in governing client contract.

Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we
can not guarantee that any email or attachment is free from computer viruses and
you are strongly advised to undertake your own anti-virus precautions. Mascon
grants no warranties regarding performance, use or quality of any e-mail or
attachment and undertakes no liability for loss or damage, howsoever caused.

On Wed, 28 Nov 2007, Benjamin Jacob wrote:
> The AGI scripts have been written in PHP, using MySQL for the billing 
> and profile information.
> The major disadvantages I see using AGI scripts :
> 1. A new process(invocation of PHP scripts) on every new call.
I write all of my AGIs in C. While PHP is PDF (pretty darn fast), it 
cannot compare to C.
> 2. MySQL connections on every instance of the PHP AGI script. (I am not 
> too sure, if connections can be maintained across processes, am no PHP 
> guru. I think, if I write in C/C++ can use shared memory for maintaining 
> the connection).
When a process exits, all files, sockets, pipes, etc. are closed. You 
cannot maintain a connection across processes.
> Any ideas anyone?or any similar experiences, in terms of performance, 
> scalability, etc. w.r.t both AGI scripts and AstMan API?
I wrote a chat system that handles about 15,000 calls a day, peaking at 
about 100 simultaneous calls. About 90% of the calls execute 6 AGIs, the 
other 10% range from 10 to 50 AGIs. One of the AGIs is even muti-threaded 
-- 1 thread plays "please wait while..." as another thread authorizes 
their credit card. By the time the sound file has finished I know if the 
card is good or not.

AGIs get a bad rap for performance, but I think that is largely due to 
AGIs written in scripting languages. The 1.6gHz Celeron ("whit-whoo")
I'm
working on right now, will execute over 100 AGIs per second. (The 
"null-agi" I just cobbled up reads the AGI environment variables and
then
exits.)

If performance actually becomes a problem, you can re-code your 
application as an Asterisk application. Then you skip the cost of process 
creation and can maintain state and connections.

The same slug used above will execute over 1,000 NOOPs per second.

Thanks in advance,
------------------------------------------------------------------------
Steve Edwards      sedwards at sedwards.com      Voice: +1-760-468-3867 PST
Newline                                             Fax: +1-760-731-3000

I have found out that executing AGI thru the AMI interface fill better
my needs of control. Take a look

http://bugs.digium.com/view.php?id=11282

Ignore the bug description and read the first note entry, that might
be a better way to get things done.

- Moy

On Nov 27, 2007 10:27 PM, Benjamin Jacob <benjamin.jacob at mgl.com>
wrote:
> Hello ppl,
>
> Have implemented a really nice Billing engine using AGI scripts. So far
> it works fine, tho haven't yet put it in the torture cell.
>
> The AGI scripts have been written in PHP, using MySQL for the billing
> and profile information.
> The major disadvantages I see using AGI scripts :
> 1. A new process(invocation of PHP scripts) on every new call.
> 2. MySQL connections on every instance of the PHP AGI script. (I am not
> too sure, if connections can be maintained across processes, am no PHP
> guru. I think, if I write in C/C++ can use shared memory for maintaining
> the connection).
>
> So, to overcome these issues, I was thinking of using AstMan APIs along
> with astmanproxy, with the setup being something like this :
>
> Asterisk <---------> astmanproxy <-----------------> Billing
> Engine(control/access)
>
> Has anyone ever tried this?
> The one seriously big work with this approach would be to have an FSM
> built into my billing engine, maintaining call states, etc. That seems
> to be quite a daunting task to be done in a short time.
>
> Any ideas anyone?or any similar experiences, in terms of performance,
> scalability, etc. w.r.t both AGI scripts and AstMan API?
>
> TiA
> - Benjamin Jacob.
>
>
>
>
>
>
> EMAIL DISCLAIMER : This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to whom
they are addressed. Any unauthorised distribution or copying is strictly
prohibited. If you receive this transmission in error, please notify the sender
by reply email and then destroy the message. Opinions, conclusions and other
information in this message that do not relate to official business of Mascon
shall be understood to be neither given nor endorsed by Mascon. Any information
contained in this email, when addressed to Mascon clients is subject to the
terms and conditions in governing client contract.
>
> Whilst Mascon takes steps to prevent the transmission of viruses via
e-mail, we can not guarantee that any email or attachment is free from computer
viruses and you are strongly advised to undertake your own anti-virus
precautions. Mascon grants no warranties regarding performance, use or quality
of any e-mail or attachment and undertakes no liability for loss or damage,
howsoever caused.
>
>
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>


-- 
"Within C++, there is a much smaller and cleaner language struggling
to get out."