To maintain high recording quality with no audio skips we have found that you should not go over 50 conversations being recorded on a single server. What have you found is your limit while maintaining very good audio quality?
MATT--- On 9/16/06, Steve Totaro <[EMAIL PROTECTED]> wrote:
Right now we are all inbound and every call is recorded. Matt Florell wrote: > Hello, > > At this point in time VICIDIAL is more focused on outbound features, > but inbound and blended capcbilities have been part of VICIDIAL for > about two years. The most I have done inbound-only with it is 3 T1s > with 60 agents. But for outbound and inbound agents together we have > had upto 120 agents on one setup with 20 T1s(spread across 8 Asterisk > servers, 2 web servers and 1 MySQL server) handling over 200,000 calls > a day(mostly outbound of course). > > The inbound portion of VICIDIAL does not have customized hold music or > periodic announcements yet, but we plan on adding those features in a > future version as we begin to focus more on inbound in the project. > > We do use meetme rooms in VICIDIAL. This allows for easy third-party > calls and multiple monitoring/manager intrusion into an agent session. > > The load balancing works by having the Database keep track of agents > and calls for all of the servers and then use IAX to move the calls > from where they originated to whoever the next available agent is, no > matter what server they are on. So the calls can come from anywhere > and the agents can be logged in anywhere. > > If you receive inbound callerID on these calls you will also be able > to have caller information appear on the Agent's web interface. And if > they are a customer that is already in the system it will bring up > their existing record. > > As for reliability, we have not had a total system failure in the last > 2 years(aside from long power outages and hurricane interruptions). > MySQL can handle a tremendous volume and it is the only > total-system-single-point-of-failure in VICIDIAL, ours never crashes. > The web servers can be load balanced(no need for session-awareness) > and you can use any Apache/PHP webserver that may be on your system to > serve the AJAX-based agent web interface. As for Asterisk, we have had > servers crash periodically(a couple crashes a month across 8 servers), > but that is to be expected when you push tens of thousands of calls > through each one per day. > > Will you be recording all calls in this setup? > > MATT--- > > On 9/16/06, Steve Totaro <[EMAIL PROTECTED]> wrote: >> Matt, >> >> I am sure this is a RTFM and I am pretty sure you are using meetme >> rooms. Just not too sure how you do the magic. >> >> 28 T1s with NFAS so 95 channels per trunk group, seven trunk groups = >> 665 lines. My client's call volume has shot from 5,000 to about 10,000 >> calls a day. Due to recent product offerings/advertising, I expect to >> be eating up 6 T1 (peak) by the end of October. They will eventually >> have every channel in use during peaks, whether that is in November or >> December, I am not sure. I just know it can't break at that point due >> the the sheer expense of revenue lost for downtime. >> >> Thanks, >> Steve >> >> >> Matt Florell wrote: >> > How many lines and agents are you looking at? >> > >> > What kind of call volume? >> > >> > Average expected hold time? >> > >> > VICIDIAL could be an option for you since it does not use Asterisk >> > Queues and can already easily scale across many servers. >> > >> > MATT--- >> > >> > >> > On 9/15/06, Steve Totaro <[EMAIL PROTECTED]> wrote: >> >> I have been tossing around some ideas about scaling a call center >> with >> >> load balancing and redundancy and would like the comunities input, >> >> thoughts, criticism and anything anyone wants to toss in. >> >> >> >> The most evident thing is to start with beefy servers and only run >> procs >> >> that are required. All of the TDM boxes run stripped down >> versions of >> >> Linux and Asterisk, they just take the call from the PRIs and convert >> >> them to SIP, everything stays ulaw end to end. >> >> >> >> *Shared queues across multiple servers would be ideal*. I don't >> think >> >> it is possible in asterisk, as is. Maybe DUNDI could be useful >> but I am >> >> not up to speed on it enough to really know. >> >> >> >> I was toying with a concept of a DB server tracking the number of >> calls >> >> to queue(s), number of agents logged into the queue(s). Some agents >> >> will be logged into multiple queues and providing the logic to a >> series >> >> of Asterisk servers. Calls could be made to the db to determine >> which >> >> queue/server to route the call to. In this situation, duplicate >> queues >> >> would exist on several servers, so balancing would work somewhat >> if the >> >> DB made the selection on which box to route the call to and which >> box an >> >> agent should log into. FastAGI and the manager interface will >> provide >> >> the routing and DB updates. >> >> >> >> Another thought was to have one central server with all of the queues >> >> and agents, then somehow the central server would cause a >> "recording/CDR >> >> server" to send re-invites to the two SIP endpoints so that the >> call/RTP >> >> stream is moved to another asterisk server which would record the >> call >> >> and keep the CDR info. Again, this would be done with a DB to decide >> >> which asterisk (recording/CDR) box has the lightest load. It >> would take >> >> the burden of maintaining the call from the "Queue" server. I/O >> is the >> >> first bottleneck in scaling when you record each and every call. >> >> >> >> Would it be difficult to have asterisk send two SIP endpoints >> re-invites >> >> and then bridge the call? Then it is just a matter of the "Queue" >> >> server checking the DB which recording/CDR server the call should >> go to >> >> and send it a message to re-invite and bridge the endpoints. A >> transfer >> >> to a meetme is another possiblility but I want the "Queue" server >> out of >> >> the stream. >> >> >> >> Has anybody else thought through the best way to scale something like >> >> this. I have a DS3 and will be using all of the channels in the >> >> semi-near future. I need to come up with a workable plan before >> then. >> >> >> >> Thanks, >> >> Steve >> > > _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
