[asterisk-users] Asterisk concurrent calls count

Alexander Olekhnovich a.olekhnovich at gmail.com
Mon May 19 02:52:00 CDT 2008


Thanks very much for your examples

On Fri, May 16, 2008 at 8:59 PM, Sherwood McGowan <
sherwood.mcgowan at gmail.com> wrote:

> Alexander Olekhnovich wrote:
> > Hi Asterisk Users,
> >
> > I'm interested in how many concurrent calls Asterisk can process
> > without troubles. I mean 1 Asterisk server (software) like either
> > proxy or media server (any numbers will be appropriate).
> >
> > 1. Is there any limitations by the software? What is this number?
> > 2. What is the maximum count of concurrent calls you've ever seen/tested?
> >
> > --
> > Thanks in advance
> > Alexander Olekhnovich
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > -- 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
> Rather than jump into the heavy list of replies, in which there's some
> heated discussion, I thought I'd offer a quick $0.02:
>
> Asterisk's concurrent call capabilities is limited (as far as I know)
> only by the hardware you're using and the implementation. By this I mean
> that the amount of transcoding, meetme conferences, SIP/IAX/Zap
> channels, recording, CDR backend, etc...all take their toll on your
> hardware's capabilities.
>
> I'll give you two examples:
> 1. On a Dual 1.5Ghz XEON, 2GB RAM server running CentOS 4.5(unsure on
> this anymore) with only Asterisk 1.4 TRUNK in 1995 in a SIP only
> environment with ONLY ulaw encoding, I've seen 500+ concurrent calls
> with over 2K users on a single machine. All clients were set for
> canreinvite=no, and qualify=yes. This system did not show degradation of
> performance.
>
> 2. I'm currently working with a client that has a Dual 2.5 Ghz, 2GB RAM
> server, running Debian Etch. They are running two EM Wink T1 Trunks, and
> 51 Zap phones locally running through Adtran Total Access Channel Banks,
> 12 POTS lines running through a Rhino channel bank, and 27 SIP Phones.
> Concurrent calls only run at around 43 calls currently, although I've
> seen it as high as 53, and ALL calls are recorded other than local
> spying on channels and inter-extension calls. Additionally, this server
> has PostgreSQL and Apache running on it to allow administration to
> review CDRs and pull recordings, and a Zabbix monitoring agent daemon
> sending data to a local network Zabbix server.  This server showed
> little or no degradation in call quality or service (even with Sox and
> Speexmix running in the background converting recordings via a
> background script) until just recently when we changed T1 providers and
> got EM Wink instead of the requested PRI. Before we had 99.999% of all
> calls complete from dial to hangup with no issues. Now we're at 98.8%,
> with calls being dropped in midconversation. I have not found the answer
> to what is causing the server to drop calls, other than after the
> switchover to EM_W our Zaptel accuracy started degrading. We are in the
> process of figuring out how we can resolve this, including possible
> hardware upgrades (which were already planned for handling recordings
> better)
>
> I hope these two examples help show you how two similar machines can
> vary drastically in performance with similar hardware. Differences in
> implementation make a BIG difference.
>
> Slainte,
> Sherwood McGowan
>
>
> _______________________________________________
> -- 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
>



-- 
Best Regards
Alexander Olekhnovich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080519/5104ee2b/attachment.htm 


More information about the asterisk-users mailing list