[asterisk-users] Scalability and stability matters

[Jose Arias]

Many thanks Matt,

I heard asterisk had some problems with registering over 100 SIP endpoints
and I was worried about how much the transcoding load could be for over 100
concurrents calls too. I expect to be over these figures. Regarding the AMI
connection, yes, there will be only one, like any third-party cti-link but
my concern was about how many commands an events asterisk is able to handle
without becoming in a bottleneck.

You said you're using about 8 patches. Are all of them to make sure the
stability and scalability of the system? Well, one of them is the AsyncAGI
patch, isn't? Is there anyone to mach originate commands with new_channel
events?

I'm planning to use asterisk 1.4.18

Regards
Jose


2009/7/21 Matt Florell <astmattf at gmail.com>

> 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---
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090721/7fea9767/attachment.htm