[Asterisk-Users] Large Asterisk Setup (~500 Concurrent Calls
+Scalability)
Wiley Siler
wsiler at education2020.com
Wed Apr 20 19:15:43 MST 2005
Interesting setup. Love to hear more about it as you get it done.
Regarding your DSP/PCI Bus.... I think that I saw that Sangoma cards may not have the same problem.
Something to check out at least.
Also this card looks impressive if it ever materializes. Think it is still vapor though. Anyone got these yet?
http://voipstore.atacomm.com/shops/ViewItem.aspx/27934028032-38356249088.htm
DSP onboard!
Luck!
Wiley
________________________________
From: asterisk-users-bounces at lists.digium.com on behalf of Matt Roth
Sent: Wed 4/20/2005 1:10 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: [Asterisk-Users] Large Asterisk Setup (~500 Concurrent Calls +Scalability)
List Members,
I am involved in the process of designing a large Asterisk setup for a
call center. A graphical overview of our tentative design can be found
here:
http://home.comcast.net/~mroth01/LargeAsteriskSetup.gif
Originally, we planned to implement this design by purchasing one
multi-processor machine and putting multiple quad-span T1 cards
(Wildcard TE4xxPs) into it. Through research, it was determined that
the PCI bus couldn't handle the digital signal processing (DSP) from
more than one quad-span card.
The goal of our new design is to offload the DSP to the Asterisk slave
servers, then route the calls via IAX2 trunks to the Asterisk master
server. The Asterisk master server will provide us with a centralized
point for queuing, digital recording, and music on hold, as well as
configuration, monitoring, and reporting. Configuration of the Asterisk
slave servers would be limited to setting up extensions to terminate the
incoming T1s and setting up IAX2 trunks to the Asterisk master server.
These configurations would be rare, so the slave servers would be
configured manually on the boxes themselves.
Failover of the primary slave servers will be provided by backup slave
servers configured to mirror one or more of the primary slave servers'
extensions and IAX2 trunks. The master server will be mirrored as
well. On failure, automatic T1 switching is an option, but we would
initially be doing it manually.
Scalability is provided by adding machines to the slave server pool, up
to the point where the master server can no longer handle the call volume.
An example of a typical incoming call's flow follows:
- The call originates from the PSTN and reaches an inbound Asterisk
slave server via an inbound T1.
- The Asterisk slave server handles DSP and routes the call to the
Asterisk master server via an IAX2 trunk.
- The Asterisk master server handles queuing the call and eventually
routes it to a SIP phone via a SIP channel.
An example of a typical outgoing call's flow follows:
- The call originates from a SIP phone and reaches the Asterisk master
server via a SIP channel.
- The Asterisk master server routes the call to an outbound Asterisk
slave server via an IAX2 trunk.
- The outbound Asterisk slave server handles DSP and passes the call off
to the PSTN via an outbound T1.
Note that the master server must handle protocol bridging between IAX2
and SIP, but will not have to do any transcoding because we can control
the codecs used on the servers and the SIP phones. Digital recording as
well as monitoring, reporting, and configuration tasks will be offloaded
to client machines via mounted drives and the Asterisk Management API in
order to lessen the burden on the Asterisk master server. The Asterisk
master server will also be responsible for opening a socket connection
to an agent station on each incoming call in order to pass the phone
number that the call came in on.
We have done a lot of research and were unable to find any documented
cases of a centralized design of this scale. This is our preliminary
design and is apt to have a few holes, mistakes, and possibly
deal-breaking oversights. Please provide any opinions that you have on
the overall feasibility of this design as well as any hardware
recommendations for each of the components or suggestions for improving
the overall scheme. If you see any bottlenecks we have overlooked,
please point them out and give any suggestions for circumventing them.
Any ideas on how large this system could be scaled would also be
appreciated.
I also have a question regarding DSP: Does outbound DSP (digital to
analog) require less processing than inbound DSP (analog to digital),
and if so by what ratio?
There is a spot on the wiki
(http://www.voip-info.org/wiki-Asterisk%20hardware%20recommendations)
regarding this size Asterisk setup, but it has not been addressed yet.
Hopefully, this will be the start of filling in that hole.
Thank you for your time,
Matthew Roth
http://voip-info.org/tiki-index.php?page=Running%20Asterisk%20on%20Debian
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 7883 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20050420/d4577360/attachment.bin
More information about the asterisk-users
mailing list