Hello everyone,
Got a question:
Reading the “Asterist The future of Telephony” book, I found a table showing purpose, number of channels and min. hard recommended.(page 10)
What exactly is number of channels? it seems “concurrent calls”. Am i right?
If I have 200 users connected to Asterisk server, how many connected users should I predict?
Thanks in advance
William
That is a difficult one, as it is highly dependent on what type of application your instance will be used for. Is this a call center, an office full of knowledge workers, a mix, etc? There are scenarios, with call center specifically, where you may have more calls (therefore simultaneous connections) than you do users…
Best to look at historical data and make some assumptions based on that.
Using the sipp tool, we managed to simulate 120 simultaneous calls on an Asterisk system. Hardware was a single processor 2.8Ghz Xeon. Sipp itself doesn’t generate RTP traffic, but I had each call play a sound file of duration 45s and had Sipp echo the RTP packets. I hope I’m not missing something here but it performed really well, and I’m sure we could have gotten more simultaneous calls on it.
One funny thing was that for all the calls there was only one instance of mpg123 running, maybe because I was playing the same sound file on each channel. I’d like to do it again and have Asterisk play random sound files. The Asterisk TFOT book says (page 10) that >15 channels is a medium to large system. That seems like a very small number.
Codec was G711
I suppose it would also depend on the method of RTP delivery.
If you do not pass all RTP packets through the Asterisk server, but rather directly from peer to peer, (SIP phone to SIP phone) the system could support a vast number of callers. Using re-invites would allow this.
This would limit the actual RTP traffic load on the Asterisk server to any calls on hold (for music on hold), calls that go to voicemail, or calls leaving the local system to traverse the PSTN.
Even then, the system could be broken up into multiple servers. The voicemail server, for example, could be a server all it’s own. The same could be true for a PSTN gateway.
About the only thing Asterisk would have to do then would be to maintain the registrations and process the requests for any service based on the extensions.conf file’s configuration. SER could help with the registrations (in large systems), leaving Asterisk to just process the invite/re-invite requests. Basically, Asterisk as sort of a “DNS” for VOIP traffic.
This configuration would be fairly easy for any server to maintain…
We passed all RTP traffic through Asterisk.
Working out how to break Asterisk up into multiple servers appears to be harder than finding the holy grail. No one has any answers about how to maintain peer(ie phone) information amongst all Asterisk boxes.
Today I mocked up the idea of having phones register with SER, and then sending all outgoing calls through SER (the stupid Polycom phones won’t accept different registrar and proxy hosts or I would have sent outgoing calls through Asterisk). Anyway, when making a call, SER needed to decide what Asterisk box to use. I discovered very fast that eventhough the docs SAY that OpenSER fully supports SRV lookups, it DOES NOT. It appears that SRV lookups only work with the t_relay command, and I need to use the forward() command. Then I tried putting a host name as an argument to the forward() command but discovered (with ethereal) that OpenSER only does a DNS lookup on host name specified in openser.cfg at startup, NOT during call processing.
This is all becoming grossly frustrating due to inadequacies in both Asterisk and OpenSER.
Oh, I agree!
Many things are extremely frustrating with Asterisk. It’s really a development environment. Not a finished product.
I really think that it’s meant to be a springboard for new systems/services by providing some basic functions.
After that, I believe that we were meant to fix our own problems and make it work the way we want by introducing our own code.
Sadly, that’s not something that most people can do.