[asterisk-users] Scalability and stability matters

[Matt Florell]

> 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---
On 7/21/09, Jose Arias <cyr2242 at gmail.com> wrote:
> 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
>
Hello,

We don't use AsyncAGI at all, the patches to Asterisk are mostly for
issues with waitforsilence, chan_sip, AGI defunct channels and gsm
codec. We also add patches for changed meetme enter/leave sounds and
Sangoma CPD SIP message processing.

We match Originates to new channel using code in our AMI listener app.

MATT---