[asterisk-app-dev] ARI in production

Damir Kalashnikov kalashnikovdamir at gmail.com
Mon Jun 16 18:17:28 CDT 2014


>
> 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.


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.

Damir


On Tue, Jun 17, 2014 at 12:43 AM, Paul Belanger <
paul.belanger at polybeacon.com> wrote:

> On Mon, Jun 16, 2014 at 6:13 AM, Damir Kalashnikov
> <kalashnikovdamir at gmail.com> 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 at polybeacon.com | IRC: pabelanger (Freenode)
> Github: https://github.com/pabelanger | Twitter:
> https://twitter.com/pabelanger
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20140617/57236021/attachment-0001.html>


More information about the asterisk-app-dev mailing list