What the recommand confiuration of asterisk for 1200 users?


#1

I am a new user in asterisk. Due to cost down the cost on normal PBX. We decide to use asterisk as our PBX system in the coming years.

We have 1200 users. Conference call, voice mail, VoIP is our basic requirment. What is recommand configuraiton of our system? How many T1/E1 cards do we need? Actually I have no idea on these issue. By now we must establish a small testing system to evaluate asterisk. How many and what other hardware I need?

I have installed asterisk on our PC (Fodora linux based). But I could not start the SIP protocal on the machine. Does T1/E1 cards need to start up this protocal?


#2

i’ll take a stab at this…

the most important numbers i can think of are the following:

how many active internal calls do you expect to have at one time?
how many active external calls do you expect to have at one time?

those numbers should give you an idea of what size box to get, as well as how many T1’s you’ll need. for instance, if you assume that your 1200 users will generate 120 internal calls and 240 external calls at any one time, then you’d probably need one very fast or two smaller servers, each with two quad-span T1 cards (for some overhead - 96x2 = 192 lines per box). That’s if you’re not doing a bunch of transcoding and using something like ulaw. If you’re transcoding to g729 and recording every call and running 10 conferences, then you’ll need a beefier machine.

Our company did it like this (~400 seats, spread over 8 ‘internal’ companies) - we used one dell 2850 per ‘company’ for about 50 users each…we have enough overhead to double or triple the size of each company and not have to upgrade our servers, plus it makes for easy maitenance - if we have to bounce a server, only one company is affected…perhaps you could take a similar route. One server for sales, one for support, etc…

read this if you haven’t: voip-info.org/wiki/view/Asterisk+dimensioning

As for a test box, there are about 600 guides on the internet - in a nutshell, you need a T1/E1 card if you want to test connectivity to the PSTN…your server doesn’t need to be anything robust, our first build was on a desktop machine.

then download an install zaptel, libpri, and asterisk, in that order (zaptel assumes you are using a digium card). past that, it’s all dial plan work…

good luck, and have fun…


#3

Thanks for your reply. I am trying to find guides on the internet to implement our testing system.
But i still have questions, we need to keep current phone sets, we are using the phone set of SIEMENS (Module: SIEMENS Opti. Standard 500). It seems this type of phone set does not support SIP and H.323 but it supports PRI. Which protocal is suitable for us in future?


#4

i’m assuming you will need some sort of ATA (analog telephone adapter) or channel bank to interface between the older analog set and the asterisk server.

i may be totally mistaken on this - i’m not familiar with a PRI capable handset…

one thing we did was to install the wildcard TDM2400, which has a amphenol connector, which we were able to connect to one of our existing patch panels, and we could patch straight through to the desk ports - works great, with a minimal amount of cabling.

that is the least obtrusive option i can think of, but like i said, this isn’t my area of speciality…we’re using all SIP phones, most of which are softphones (which is great - talk about easy), so i’m not the best resource on this.


#5

Morning :smile:

–> 1200 users: The “endserver” should be at least a dualcore CPU since echocancellation and MOH/voicemail is a CPU hog.

I also think, depending on the business/phone behaviour, that you might need a quad spawn T1 card, giving you more then 100 lines for concurrent calls. Check on the current PBX how many concurrent calls a taking place normally.

Dont have a SQL server or anything else running on that machine:
Asterisk exclusive !

A database can run somewhere else in the net, but not on the asterisk machine.

Reason: Dualcore CPU from AMD is better for servers, but for “multimedia” desktop stuff, the pentium dualcore is better.

Ironically, the codecconversion, echocancellation and MOH/voicemailstuff is exactly what you would normally consider “desktop multimedia”, so go wtih a pentium dualcore for asterisk !

Well, this all is only valid if the server has high load. If only 108 of the 1200 users are busy and only 30 of the 108 doing concurrent calls, then a standard 3 GHz will handle it with a bored smile :stuck_out_tongue:

we are using the phone set of SIEMENS (Module: SIEMENS Opti.
Standard 500)

Im sorry to hear that :stuck_out_tongue:

These are SYSTEM telphones, means: They ONLY run on the hicomm and hipath PBX of siemens with its own propiatary (SP?) protocol.

There IS a “Opt ISDN adapter” doing a conversion, enabling the opti 500 std. to work on standard S0-protocol. But this isnt working for you since such “bridging” needs a S0 port FOR EVERY SINGLE phone connecting to asterisk. You wont find such “card” or “hub” - and if you do, it will come that $$$$ that you forget about it anyway …

Nope Sir, your only chance is to change the phones as well.
If your users are used to such comfort like the siemens offers, you might want to go with SNOM 360, (Cisco is way more expensive).


#6

[quote=“RichardHH”][quote=“whoiswes”]
your server doesn’t need to be anything robust, our first build was on a desktop machine.
[/quote]

Morning :smile:

–> 1200 users: The “endserver” should be at least a dualcore CPU since echocancellation and MOH/voicemail is a CPU hog.
[/quote]

that was for the test build…not the live server. and i think you’d need way more than one dual-proc machine for 1200 users…a quad-proc might do it, with about 8GB of RAM…i guess it all depends on transcoding and conference usage.


#7

Is the linux kernel and/or the current 3.3 or ++ compiler supporting quads ?

I think, that the number 1200 isnt the key here, its the load the users producing, actually logged in and “moving” the server.

I could think of companys with 1200 phones but only like 100 in use.
On the other hand, there are companys with 300 seats producing traffic on all phones simultan (eg. prof. callcenter).

I think, we need to figure out, what business and phonebehaviour we have here.

Then we sell him unwanted, unessecary overprized stuff… LMAO :smiling_imp:
(Joking…)


#8

PS::

8 GIG…asterisk isnt using much RAM.
Its leaking much tho…LOL ! (not really).

Most RAM is used by Linux for the caching and buffering, but asterisk itself just holds the “registry” in memory (and the very *code of course).

I figured the RAM consumption is pretty low, we handle 2000 calls per day with like 50 devices and dont exceed 30 MB RAM, tho the inital RAM is already like this, so not much growing while running (except memory leaks).

Considering the current highmem mechanism of linux, i would go for 2 GIG with the “splitpatch” (from 4G down to 2G).

I built another asterisk “spare server” on eastern, without Gnome or KDE, just a plain debian with only the needed modules.

28 MB RAM on start, went up to like 40 in use. Very less hungry little bugger that asterisk :stuck_out_tongue: (correct english?)


#9

our servers handle 60,000 calls per day in total, but we’re ramping up at a 10-20% increase monthly, and we’re doubling our agent count from ~350 to around 700-800 within 6 months. because we overbudgeted our servers when we built them, we have more than enough overhead to grow…that is my number one fear when dimensioning anything - future-proofness. i always figure a worst-case scenario for usage, then double it. in my admittedly short time in the professional IT world, i’ve found this to be a good practice…

i am also a firm believer in never having too much memory, especially since it’s so cheap anymore. we also are running mysql and httpd, and we record every inbound and outbound call to disk (not on the asterisk server, on our SAN) so the extra memory and overhead comes into play there.

i agree that more info is needed - if he is only going to have 30 active calls at once, a basic single proc dell server would probably work out alright, but if they double capacity (to just 60 calls) then he’d probably be up against a wall…add in a conference or two and the server would probably be toast. i don’t even want to think about any transcoding…that is one thing that we have not had to do (our entire network is gigabit), but i’m pretty sure transcoding 50 simultaneous streams would eat up a chunk of CPU, even on our hefty servers.

i think that someone needs to come up with a dimensioning matrix, where we can go enter our hardware config, the number of users/calls/codecs/etc, along with average CPU/etc to get a better idea of what is required for various installations.

BTW, richard, would you mind sharing a bit more about the ‘splitpatch’ - i’ve never heard of that, sounds interesting (the more you know…)


#10

Evening :stuck_out_tongue:

“Splitpatch”:
As far as my young linux knowledge goes (i just started with linux after a long time of Windows®) :

If a Linuxkernel is compiled with highmem off, its using 860 (or 905) MB of your RAM, no matter how much stick into the machine.

Highmem=on:
Splits your memory at 4 GB, from what ive read so far.

In some cases, you dont WANT highmem enabled but use eg. 2GB of RAM (of course…youve payed for it:P )

Then the patch comes in:
kerneltrap.org/node/6067

Well, from what ive understand…

To the very topic:
Well, i totally agree, as long as some is paying for the “rich dimensioning” i dont care…hehehehe :smiling_imp:

Im running on 3GHZ with native ISDN prcoll (711).
10-15 concurrents are giving me 3-8 % CPU load on the sys-mon, up to 18% with an opened X-console (VNC).

There is MOH (raw), voicemail, queue music with announcement and echocancellation, no codeconversion.

Im pretty satisfied with that performance, knowing even a full loaded PRI E1 (30 channels) would prolly not exceed any higher number on the CPU.

But a quad PRI fully loaded will have a huge multiplicationfactor, i totally agree.

might be able to handle more then the one PRI E1 interface


#11

[quote= and we record every inbound and outbound call to disk (not on the asterisk server, on our SAN) so the extra memory and overhead comes into play there.
[/quote]

Hi Whoiswes:

Could you explain a little more about this setup please? I need to setup call recording on all in and outbound calls aswell and would appreciate any input.

Thank you.


#12

sure, basically we have a stdexten macro for all inbound calls, and i set the monitor filename and call the monitor app in that macro:

[macro-stdexten] exten => s,1,SetVar(CALLFILENAME=INCOMING_${TIMESTAMP}_${CALLERIDNUM}_${MACRO_EXTEN}) exten => s,2,Monitor(wav,${CALLFILENAME},m) exten => s,3,Dial(${ARG1},${ARG3},rt) exten => s,4,Voicemail(u${ARG2}) exten => s,5,Hangup exten => s,104,Voicemail(b${ARG2}) exten => s,106,Hangup

that takes care of inbound calls.

outbound, we have a macro for local/toll-free and LD dialing - we do the same thing:

[macro-tl-dialout] ignorepat => ${DIALOUT} exten => s,1,Set(CALLFILENAME=OUTBOUND_${TIMESTAMP}_${CHANNEL:4:3}_${MACRO_EXTEN}) exten => s,2,Monitor(wav,${CALLFILENAME},m) exten => s,3,Dial(${TRUNK}/${MACRO_EXTEN:${TRUNKMSD}}) exten => s,4,Hangup

that’s it - we have a cronjob that runs once an hour that encodes to MP3, then another job that copies over to our SAN. it’s quick and dirty and could be made much more efficient (not recording unanswered calls, etc) but it works for now and doesn’t cause too much overhead…although we can get CPU usage spikes up to 40% or so when call volume is high and the files are being encoded.

hope this helps!


#13

hmm…since the codec is only about 8 KB/s, why not streaming the monitoring directly to a non-local hardware (samba share?) and doing the conversion there ?

That way no HD stress, no accesses and no conversion load ?


#14

that is on my to-do list…our SAN has been in flux for a while now, as we’ve upgraded the storage array and are still ironing out all of the minor bugs…we’ll be replacing the actual SAN server here in a week or so, and once all that is done, i will probably do exactly that - that would axe two cron jobs, as well as allow the managers to access calls that just completed, versus having to wait an hour.

i just need to wait until our SAN is rock solid, which, at this time, it’s not…

i’d love to convince the higher-ups of running the asterisk servers off of a RAM disk, and load the entire OS off of a usb keydrive or something similar…it probably won’t happen anytime soon, but here’s to hoping.


#15

What could be the advantage of a ramdisc asterisk ?

Well, technically - Asterisk IS running ramdisc-like already.

The only hd access is when it starts, reading all CONF into RAM.

The rest is Linux, caching and buffering everything anyway, so yes - as long as no swap is used, the whole frigging thing is already “RAMed” :stuck_out_tongue:

On a USB stick…hmm…think think…whats the advantage, i cant think of atm, but im hungry as well…so im a bit retarded atm :laughing:


#16

a RAM disk would allow you to run diskless - no internal hard drives. the usb keydrive would contain the linux image, so that would be loaded onto the RAM disk at boot time.

the main benefit (for me, anyways) would be that if one of our servers had a catrastrophic failure, i can simply swap the USB keydrive to our backup server, patch over the T1 cables to the backup, and have our phones back online in a few minutes. it would also make building a new server trivial - you’d have to duplicate the USB keydrive image and set up your dialplan (which you could load from a database, ala Realtime) - a new server build in minutes.

these are all just thoughts, not really even on paper, but having seen and used AstLinux (entire asterisk server that boots off a 32MB compact flash drive) and played with Realtime, i think there are quite a few opportunities to utilize these technologies in a production environment.


#17

But this would require a EXACTLY hardware “clone” of the original server, right ?

Cause the “imaged” linux has the hardwareinfos, devices and kernelconfig based on that.

I just built a “backup server” here, but made a complete fresh setup on the new machine, cuz its diff. hardware.

Correct ? (im still a Linux newb)


#18

honestly, i’m not sure…probably the same chipsets, etc - not the exact same machine, but something close…since we use identical servers for all our asterisk boxes (hard drives are the only thing that aren’t the same, a few have larger drives) it wouldn’t matter for us.

i THINK it’s sorta like windows - you can get by if the drivers still exist and the HAL hasn’t changed drastically, but there are only so many changes you can make before the image blows up.

i’m a linux newb too, most of this info is supposition based on what i’ve found on the web and reading up on projects like astlinux (which has worked fine on the two intel-based boxes i’ve tried running it on). if/when i have some free time, this would be one of the things i’ll work on as a side ‘fun’ project…eventually it may bear something useful, but probably not for a LOGN time…


#19

[quote=“whoiswes”]
that’s it - we have a cronjob that runs once an hour that encodes to MP3, then another job that copies over to our SAN. it’s quick and dirty and could be made much more efficient (not recording unanswered calls, etc) but it works for now and doesn’t cause too much overhead…although we can get CPU usage spikes up to 40% or so when call volume is high and the files are being encoded.

hope this helps![/quote]

Yes it sure does - that is exactly what I am doing - also having a “cron job” but mine is running on a Windows server that grabs the recorded files via ftp so the MP3 encoding does not happens on the * box. I asked the question cause it seemed like you were recording straight to the SAN so I was curiuos about that but it turns out we are doing the same thing. BTW I use LAME and 16kbps seems to be a good bitrate.

Thank you.