[asterisk-users] Large Asterisk system
Hi, what hardware (and distro) would you recommend to run an * box with 2500 SIP peers each doing 100 minutes of calls a month? No transcoding at all - all calls will be g729. According to my calcs if the calls are mainly spread over an 8 hour period each day that is (2500*100)/(8*60*30) = 17.36 Thus an average of 17-18 simultaneous calls at any given time but obviously it will peak much higher than that. Tx Marnus van Niekerk -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." Thomas Alva Edison - Inventor of 1093 patents, including the light bulb, phonogram and motion pictures. ___ --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
[Asterisk-Users] Large Asterisk System
Hey Guys I've been browsing the list looking for more information on asterisk behavior for large system. As for now I've got a project with 300 SIP Extensions to start, with future growth (scalability) Capability of recording all extensions simultaneously during peak time. And keeping the call recording for 30 days. SIP Calls being terminated over a Cisco 5400 Gateway Extra 100(+) FXO channels for incoming calls. (calls are going to be routed to the SIP Extensions. As far as I get the Hardware setup that I thought that will handle it is: Two Asterisk Server - Quad Dual-Core Opteron Servers running for call processing One SER Server - Dual Dual-Core Opteron for SIP routing and SIP 2 SIP calls (no recording) One Serial Over Ethernet Storage for recording the calls (the two asterisk servers will commit to that device) For the setup I was going to put a lot of RAM on the serves something like 8GB and make asterisk record the calls to a RAMDRIVE. Another process will run with low priority moving the Recordings from the RamDrive to the Storage. If Asterisk One dies, Asterisk two assumes. If SER dies, ASTERISK one or TWO will handle without the proxy. We need to avoid single point of failure as also be able to scale well. Other possibility that we may look is having instead of a storage, is having a Extra Asterisk getting the calls as a conference over IAX and saving it. As far as I see it will also need to deal with the real time recording on RAM. Because seek delay on multiple files being writing as small chunks of data (20ms voice data) on the HD will make voice choppy. So the solution will have to involve moving from RAM do HardDrive as the conversation ends. As I read it will be easy to record a 30megs file instead of several small chunks of 100KiloBits. As the other process can run in low priority and not realtime. It may not affect asterisk recording to RAM. Do you guys think that the servers will be able to handle that ? Does the SIP protocol can handle that redundancy ? Has anyone designed a system similar to this ? Does anyone wants to add a two cents comment on that design ? Is any company available for paid consulting ? -- Charles Rauber Gomes ___ ___ / //|/ / || / / // ) ) // ) ) // | | /__ ___/ / ///| / / || / / // / / ((//__| |/ / / /// | / / || / / // / /\\ / ___ | / / / /// | / /||/ / // / / ) ) //| | / / __/ /___ // |/ / | / ((___/ / ((___ / / // | | / / 954-585-1033 Extension 55 ___ --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
Re: [Asterisk-Users] Large Asterisk System
On 6/1/06, Charles R. Gomes [EMAIL PROTECTED] wrote: Hey Guys I've been browsing the list looking for more information on asterisk behavior for large system. As for now I've got a project with 300 SIP Extensions to start, with future growth (scalability) Capability of recording all extensions simultaneously during peak time. And keeping the call recording for 30 days. SIP Calls being terminated over a Cisco 5400 Gateway Extra 100(+) FXO channels for incoming calls. (calls are going to be routed to the SIP Extensions. As far as I get the Hardware setup that I thought that will handle it is: Two Asterisk Server - Quad Dual-Core Opteron Servers running for call processing One SER Server - Dual Dual-Core Opteron for SIP routing and SIP 2 SIP calls (no recording) One Serial Over Ethernet Storage for recording the calls (the two asterisk servers will commit to that device) For the setup I was going to put a lot of RAM on the serves something like 8GB and make asterisk record the calls to a RAMDRIVE. Another process will run with low priority moving the Recordings from the RamDrive to the Storage. If Asterisk One dies, Asterisk two assumes. If SER dies, ASTERISK one or TWO will handle without the proxy. We need to avoid single point of failure as also be able to scale well. Other possibility that we may look is having instead of a storage, is having a Extra Asterisk getting the calls as a conference over IAX and saving it. As far as I see it will also need to deal with the real time recording on RAM. Because seek delay on multiple files being writing as small chunks of data (20ms voice data) on the HD will make voice choppy. So the solution will have to involve moving from RAM do HardDrive as the conversation ends. As I read it will be easy to record a 30megs file instead of several small chunks of 100KiloBits. As the other process can run in low priority and not realtime. It may not affect asterisk recording to RAM. Do you guys think that the servers will be able to handle that ? Does the SIP protocol can handle that redundancy ? Has anyone designed a system similar to this ? Does anyone wants to add a two cents comment on that design ? Is any company available for paid consulting ? Your largest challenge(s) will be recording for that many agents/channels at the same time and splitting up some of the queue engine work for redundancy. The memory approach is a proven approach using Monitor and makes sense as memory is a faster i/o than disk, but you still will have to deal with the tiny chunks getting written at a time which is just a function of the way Monitor itself works. MixMonitor and the technology behind it queues the frames up and then writes when the queue is full, so that's a slightly better approach as far as scalability goes. We have built call center platforms for clients who have the numbers you've spoken of and are interested in working with you. Please respond to the email I sent you offlist for more information. -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --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
