I have been asked by the customer to deilver a big PBX-system based on Asterisk. The requirements are approximately:
Does anyone have any ideas about a setup like this? How much servers should I use, should I use clustering, what E1 cards, how many, etc? Any help would be mostly appericiated.
This is possible, but you have to have an intimate knowledge of Asterisk as you are stretching the ‘normal’ bounds. Based on your questions, I would recommend that you contract outside Asterisk assistance.
[quote=“vEddY”]- up to 240 lines for making outside calls from the building
When you set up this PBX, can you please inform us how did you do it?
First, you say 240 lines and 1000 conversations. Do you mean 1000/1500 ACTIVE CALLS or 1500 extensions?
Second- i’ve never done anything close to this. Look at voip-info.org/tiki-index.php … mensioning for real stories. My numbers may be way off. This is from my own opinions, what i’ve read, and the experiences of others. I do not claim for anything below to be fully authoritative on this subject. Read at your own risk.
Third- what i suggest below may be overspec’d. Decide based on your budget. Check the link above. With reinvites, Asterisk on a beefy server can handle 800-1000 calls. Without reinvites (media (voice data) passing through the * box) you don’t want more than 200-300. If you are manipulating the media, such as recording or encoding, try to avoid having more than 100.
i think part of this will be to offload and distribute as much of the load as possible. You’ll need to use both asterisk and something else, perhaps SER or siproxy in front of asterisk to offload some of the work. Such a setup also allows for multiple redundant * boxes. I would also suggest put the E1 cards in a separate box or use an E1-SIP gateway device, this way any encoding that takes place will do so on those boxes and not the main Asterisk PBX. You’ll probably want to use a low-bitrate codec like gsm, g.729 or ilbc to save network bandwidth. GSM or 729 might be better bets as ilbc takes alot of CPU time to encode. Either way, the main switching boxes should be able to pass this through without having to encode it.
As i see it, it should run something like this:
e1 lines -> (frontend asterisk boxes/encoders) -> (ser/siproxy/dundi) -> (backend asterisk boxes/switches) -> (ser/siproxy) -> phones
the frontend boxes should be beefy and be able to encode however many channels they are configured for straight into a low-bit codec like iLBC or G.729, both of which require much CPU time. They will also handle your main IVRs for incoming calls. If you use VoIP lines, all your prompts should be pre-encoded into the lower bit rate (gsm/729/ilbc) so they don’t have to be encoded on the fly. If you are going to be having near 100% utilization of your lines, I suggest don’t put more than 100 channels or so (one quad-E1 card) per box.
ser/siproxy/dundi- this is mainly for redundancy. You’ll probably need more than one backend box for all the extensions, this allows the frontend box(es) to talk to the backend box(es) without any trouble.
backend asterisk boxes- These mainly handle switching of internal calls. Your queues might be here. For 1000 simultaneous calls you will probably need more than one box, or at least want more than one.
ser/siproxy- this is to reduce load on the backend boxes. SER can handle switching of internal calls without bothering asterisk. It can also make many asterisk boxes appear to be just one SIP proxy for redundancy and failover.
This is one way of doing it. This is the centralized approach, all your phones will register to one stack of servers. You will need to ensure that appropriate network bandwidth is in place to handle this load. Your routers should VLAN voice traffic separately or even have an entirely separate network infrastructure dedicated solely to voice traffic. You will want to use reinvites wherever it is possible to.
Another approach would be hierarchal and decentralized. It would work like:
e1 lines -> (frontend asterisk boxes/encoders) -> iax trunk mode OR ser/siproxy -> (many departmental asterisk boxes (50-200 phones each)) -> phones
This approach is probably more efficient, as a good chunk of the traffic in your building will be intra-departmental (people inside the same dept. talking to each other). Extensions inside the building would be assigned patterns based on department and/or locations, so you could say all the 3xxx extensions are on server 3, the 4xxx’s are on server 4, etc. So everybody from Sales would have a 3xxx extension, Support gets 4xxx, etc. If sally from sales calls bob from sales, only the sales department server on the sales floor has to know about it, no reason to bother with anybody in the basement. It also saves a bit on overall network bandwidth, but the savings will depend on your usage patterns. If people never call other people in the same department, this model isn’t as efficient; sally from sales calling alice from support now involves both the sales server and the support server. While the call data can be reinvited directly from one phone to another, its still more setup.
IF YOUR COMPANY WANTS TO RECORD INTERNAL CALLS- this is the way you should probably do it. Recording means that by definition you cannot use reinvites. Incoming calls should be recorded at the frontend boxes right after teh E1, Internal calls should be recorded on the departmental server they originate from.
This sounds like a very exciting and fun project! I would consider at least consulting with an asterisk expert who has done this sort of thing before starting. Either way, please post what happens and how everything works, I’d be interested to learn what you do and what you learn!