[asterisk-users] Scalability and stability matters

[Matt Florell]

On 7/21/09, Jose Arias <cyr2242 at gmail.com> wrote:
> Hi all,
>
> I'm planning to develop a custom autodialer application which will be
> dealing with its own model for agents and queues, therefore it won't use
> neither asterisk agents nor asterisk queues, nor asterisk cdr. The
> application will supply the whole reporting and agent managing features by
> itself.
>
> The application will command asterisk through an AMI telnet connection using
> only the originate, redirect and hangup AMI commands plus the stream file
> AGI command (AsyncAGI patch will be required).
>
> The application will make outbound calls, then they will be redirected on
> the fly to dynamically defined meetme rooms, then the application will call
> extensions (registered endpoints) where it will know there are available
> agents in order to redirect them to the previous meetme rooms. If the
> application launched more calls than available agents it would play prompts
> while waiting for agents to become available.
>
> Since the planned features set from asterisk to be used by the application
> will be very short, but the figures can be very large (in terms of
> concurrent calls, registered endpoints, traffic on the AMI port, etc..)  I
> would appreciate if anybody can help me to find out what's the more suitable
> asterisk version to use in terms of scalability and stability:
>
> - concurrent registered endpoints (SIP and IAX)
> - concurrent two and tree party meetme rooms (whatever codec can be used)
> - concurrent mixmonitor recordings
> - concurrent playings for prompts
> - commands and events rate on the AMI port
>
> It's important to notice the advanced features from asterisk aren't a
> priority.
>
> I already looked over some links like
> http://www.voip-info.org/wiki/view/Asterisk+dimensioning
> and others but I found more questions than answers there.
>
> Thanks in advance
> Jose
>

This sounds a lot like ViciDial, which does use meetme instead of
Asterisk Queues/Agents, is already engineered to be multi-server, is
capable of placing 200,000+ outbound calls per server per day, has a
web-based GUI for configuring the system and a web-based agent
interface.


- concurrent registered endpoints (SIP and IAX)

Doesn't really matter, we've done 500+ on a single server before and
it didn't really affect load much. As for number of agents, we are
usually conservative on that front, usually we keep it under 50 agents
per outbound server, but we have done 100 before.

- concurrent two and tree party meetme rooms (whatever codec can be used)

Everything is transcoded in a meetme room to slin. ViciDial does
everything in Meetme, and while it does use slightly more resources
than Asterisk Queues, it is more stable and offers more flexibility

- concurrent mixmonitor recordings

We do not recommend using mxmonitor. It is better to have a custom
recording handling script. And if you are using Meetme for everything
you don't have to bother mixing recordings anyway.

- concurrent playings for prompts

This depends on a lot of different things, if load or playback quality
becomes an issue then you should put prompts on a RAM drive or tmpfs

- commands and events rate on the AMI port

Use a single point(or a few limited points) of entry to the AMI to
keep it working well. You should not have an AMI connection for each
agent.


We currently use a version of 1.4.21.2 that has about 8 patches
applied to it, and we have found it to be very stable in production.

MATT---