<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The real question is, if you do move your ARI application into<br>
production, are you ready (and able) to fix any issues in ARI<br>yourself? Since you will be an early adopter of ARI, don't expect<br>everything to work or be tested.  You are going to have issues with<br>ARI and you need to decided if you are conformable fixing them<br>
yourself or waiting for a fix.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>ARI is definitely a way to go and I will strongly consider using it when Asterisk 13 is out. </div><div><br></div><div>Thank you all for your answers.</div><div><br></div><div>Damir</div><div class="gmail_extra">
<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 17, 2014 at 12:43 AM, Paul Belanger <span dir="ltr"><<a href="mailto:paul.belanger@polybeacon.com" target="_blank">paul.belanger@polybeacon.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On Mon, Jun 16, 2014 at 6:13 AM, Damir Kalashnikov<br>

<<a href="mailto:kalashnikovdamir@gmail.com">kalashnikovdamir@gmail.com</a>> wrote:<br>
> Hi Ben,<br>
><br>
> Thank you for you answer.<br>
><br>
> With regards to scalability I am not so much concerned with scalability of<br>
> .NET part, I am more worried about Asterisk itself. For example, would<br>
> current implementation support having 200 concurrent channels all 'inside<br>
> stasis'? Has anyone tried out anything like that?<br>
><br>
</div>Don't scale up, scale out. Your limit of concurrent calls is always<br>
going to be limited to hardware, just take the issue ways by launching<br>
more asterisk instances each time you hit your 80% usage benchmark.<br>
<div class=""><br>
> How about stability/robustness of the ARI itself? Would you consider it<br>
> production ready? At least to the extent of current APIs? Or would you say<br>
> that I am better off using FastAGI?<br>
><br>
</div>We're in the same boat right now. We have a queue application were are<br>
getting ready to launch, however, the honest answer is we don't know<br>
if we are comfortable yet.  For the purpose of our application, we are<br>
simply playing audio and bridging channels, so functionality is pretty<br>
basically.  However, we still need to do more on our side to test<br>
capacity.<br>
<br>
The real question is, if you do move your ARI application into<br>
production, are you ready (and able) to fix any issues in ARI<br>
yourself? Since you will be an early adopter of ARI, don't expect<br>
everything to work or be tested.  You are going to have issues with<br>
ARI and you need to decided if you are conformable fixing them<br>
yourself or waiting for a fix.<br>
<span class=""><font color="#888888"><br>
--<br>
Paul Belanger | PolyBeacon, Inc.<br>
Jabber: <a href="mailto:paul.belanger@polybeacon.com">paul.belanger@polybeacon.com</a> | IRC: pabelanger (Freenode)<br>
Github: <a href="https://github.com/pabelanger" target="_blank">https://github.com/pabelanger</a> | Twitter: <a href="https://twitter.com/pabelanger" target="_blank">https://twitter.com/pabelanger</a><br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
asterisk-app-dev mailing list<br>
<a href="mailto:asterisk-app-dev@lists.digium.com">asterisk-app-dev@lists.digium.com</a><br>
<a href="http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev" target="_blank">http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev</a><br>
</div></div></blockquote></div><br></div></div>