On Mon, Jun 16, 2014 at 6:14 AM, Ben Merrills <b.merrills@xxxxxxxxxxxxxxxx> wrote:
-- Asterisk is scalable, ARI's issue (some would argue) is that you establish a connection with it for Stasis, not the other way round like FastAGI.
To that end, the current accepted work around is to have some sort of local proxy on the Asterisk instances that establishes the ARI connection for your application, and then forwards on messages (using a message bus) to a central application.
Most of what you want to do (by the sounds of it) can be done just as easily with FastAGI. ARI has a use case more in common with Asterisk Applications (e.g. app_queue etc). That's not to say however you can't use ARI for your setup.
I am not sure if anyone has a large production scale setup out there using ARI, but all being well if they have they'll chip in to this conversation. We have large FastAGI deployments out there though, so if you feel ARI might not be the best solution right now, use AGI and revisit this later maybe?
Ben
Damir 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?
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?
Damir
On Mon, Jun 16, 2014 at 6:20 PM, Ben Merrills <b.merrills@xxxxxxxxxxxxxxxx> wrote:
Hi,
A number of us are looking at scalability at the moment for Asterisk ARI (multi node etc), Paul Belanger has created a solution to work with Python and his ARI framework (https://github.com/kickstandproject/python-ari) , and I am currently investigating options for AsterNET.ARI (https://asternetari.codeplex.com/) which is a .NET framework for Asterisk ARI.
ARI itself is of course still in development and improvements and features are being added all the time. Myself (skrusty) and Paul (pabelanger) are both on IRC and I am sure he, as I would be happy to discuss what we've done in this area so far.
Ben
Damir Wrote:
Hi All,
I am new to this mailing list and maybe this question was asked before. Sorry if that is the case.
I am starting a new greenfield project and I am strongly considering using ARI. I have just started learning about ARI.
The project itself is going to be .NET based and have features like IVR, voicemail management, call routing etc.
I plan to use ARI for as much as the API provides (and I have a feeling that it will cover most of my needs) however I am not sure about its stability/scalability, I know that version 12 is not a long term release but it is still an official release.
Do you think that ARI is considerably stable/scalable ( for handling ~200 simultaneous calls) so that I can use it in production?
In many ways, ARI is "closer" to the actual Asterisk core than Asterisk's other interfaces. While any layer of abstraction that involves external communication is going to add some overhead, I'd expect that whatever performance you can get out of a machine is going to be dictated by factors other than ARI.
For example: if your intended use case is to record all calls, setting up a Snoop channel and issuing the /record operation is not going to be the bottleneck - your disk I/O will be.
A few other thoughts:
- "Scaling" is an ambiguous term. Do you mean to scale up on a single machine, or scale out? As Ben alluded to, there are things you have to consider when scaling out. Since your application connects to each Asterisk instance (currently, at any rate), a proxy to manage the location of the Asterisk servers can be beneficial. Being HTTP based, there are lots of options in this area. Scaling up, on the other hand, is much more a factor of your hardware choices and use cases.
- I would treat each of your use cases separately. Building out an IVR in ARI is much different than building a VoiceMail system. ARI works well on a model of separate application spaces, which will help keep your separation of concerns in each application clean.
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
_______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
