[asterisk-users] Scaling Asterisk: Dual-Core CPUs not yielding gains at high call volumes

Stephen Davies stephen.l.davies at gmail.com
Fri Jun 1 10:21:59 MST 2007


Hi Matthew:

Your environment sounds quite challenging and I'd be interested in the
analysis of what is limiting the throughput.

I agree that there's no easy way to distribute and single queue across
multiple boxes.

But here is a scaling idea for you.  We've used it successfully to
handle a large inbound call centre.  It also provides resilience:

1) Incoming PRIs connect to multiple boxes that we'll call the "voice" gateways.

Each box can have a proportion of your PRIs connected.  Depending on
the box power, up to 8 or so.

2) Agent registrations are spread across these same boxes.

3) Lastly you define two or more additional boxes as your queue servers.

Every queue server has defined on it all the queues you need.  But for
each queue one server is regarded as the primary and the other as
secondary.  You mix things up so in the normal event about half your
queueing calls are on each server (extend the idea for more than 2
queue servers).

Incoming calls on the voice gateways are sent to the Queue server over IAX:

exten => 1234,1,Dial(IAX2/primary1234/${EXTEN})
exten => 1234,n,Dial(IAX2/sec1234/${EXTEN}) ; if we can't get to the primary

Now when an Agent wants to login, you have their agent gateway log in
to both of the queue servers on their behalf, using an IAX2/.. channel
to get back to the agent's voice gateway.

So on the queue server we have the agents for the queue logged in as
say IAX2/voicegw1/6001, IAX2/voicegw2/6002 etc etc.

The trick is to use transfer=yes aka notransfer=no on the various
boxes.  So as soon as the call gets connected to an agent it
disappears off the queue box completely.

The nett result is that the queue servers only have to handle
customers who are still in the queue.  As soon as they get connected
to an agent the call is directly from the arriving voice gateway to
the agent's voice gateway and on to the agent.  In a proportion of the
time that even turns out to be the same box.

You can scale up the number of voice gateways as required and handle
1000s of calls "connected" to agents without needing supercomputers.

You still handle all the people queueing on a particular queue all on
the same queueing server.  So you can tell them where they are in the
queue and all that.  But you can split up your queues across multiple
boxes to help divide and conquer the load.

If you can reach the agent phone directly using IAX (use an IAX
softphone or something) you can make a little optimisation and log
IAX2/agentipaddress into the queue directly.  Then the call gets
optimised to go directly from the incoming voice gateway to the
agent's PC.

Resilience?  If a queue server is down, new callers will automatically
start to queue on the backup box for the queues affected.  The agents
are known on both primary and backup queue boxes so things keep going.
 If a voice gateway goes down you lose just some of your PRIs, so you
are still in business.  If you need the capacity, use an ISDNguard to
kick the PRIs onto one of the other voice gateways.  Agents that were
on the voice gateway that went down will need to reregister to a box
still running.  IP address takeover can make that happen.

For me this sort of design is much better than one giant box.

Regards,
Steve Davies
Technical Director
Connection Telecom (Pty) Ltd


More information about the asterisk-users mailing list