[asterisk-users] Asterisk concurrent calls count

[Sherwood McGowan]

Alexander Olekhnovich wrote:
> Thanks very much for your examples
>
> On Fri, May 16, 2008 at 8:59 PM, Sherwood McGowan 
> <sherwood.mcgowan at gmail.com <mailto: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
> ------------------------------------------------------------------------
>
> _______________________________________________
> -- 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
Alexander,
No problem :)