Hi Ben,
I have started using it today. It is really good and will save me heaps of time.
Thanks!
Damir
On Tue, Jun 17, 2014 at 5:35 PM, Ben Merrills <b.merrills@xxxxxxxxxxxxxxxx> wrote:
Hi Damir,If you’re using .NET for your FastAGI application, I suggest you checkout AsterNET (https://asternet.codeplex.com/) . We have a number of samples to help get you started too. Good luck!BenFrom: asterisk-app-dev-bounces@xxxxxxxxxxxxxxxx [mailto:asterisk-app-dev-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Damir Kalashnikov
Sent: 17 June 2014 00:17
To: Asterisk Application Development discussion
Subject: Re: ARI in productionThe real question is, if you do move your ARI application into
production, are you ready (and able) to fix any issues in ARI
yourself? Since you will be an early adopter of ARI, don't expect
everything to work or be tested. You are going to have issues with
ARI and you need to decided if you are conformable fixing them
yourself or waiting for a fix.In my situation, considering that I am no Asterisk expert and that I am expected to deliver a robust solution within short time frame, it seems obvious that I will be better off working with FastAGI using long term version 11 release of Asterisk.ARI is definitely a way to go and I will strongly consider using it when Asterisk 13 is out.Thank you all for your answers.DamirOn Tue, Jun 17, 2014 at 12:43 AM, Paul Belanger <paul.belanger@xxxxxxxxxxxxxx> wrote:On Mon, Jun 16, 2014 at 6:13 AM, Damir Kalashnikov
<kalashnikovdamir@xxxxxxxxx> wrote:
> Hi Ben,
>
> Thank you for you answer.
>
> With regards to scalability I am not so much concerned with scalability of
> .NET part, I am more worried about Asterisk itself. For example, would
> current implementation support having 200 concurrent channels all 'inside
> stasis'? Has anyone tried out anything like that?
>Don't scale up, scale out. Your limit of concurrent calls is always
going to be limited to hardware, just take the issue ways by launching
more asterisk instances each time you hit your 80% usage benchmark.
> How about stability/robustness of the ARI itself? Would you consider it
> production ready? At least to the extent of current APIs? Or would you say
> that I am better off using FastAGI?
>We're in the same boat right now. We have a queue application were are
getting ready to launch, however, the honest answer is we don't know
if we are comfortable yet. For the purpose of our application, we are
simply playing audio and bridging channels, so functionality is pretty
basically. However, we still need to do more on our side to test
capacity.
The real question is, if you do move your ARI application into
production, are you ready (and able) to fix any issues in ARI
yourself? Since you will be an early adopter of ARI, don't expect
everything to work or be tested. You are going to have issues with
ARI and you need to decided if you are conformable fixing them
yourself or waiting for a fix.
--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger@xxxxxxxxxxxxxx | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger
_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
_______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
