[Asterisk-Users] Re: 5, 000 concurrent calls system rollout question

[Mike Hammett]

Why is using ulaw or alaw an unlikely scenario?  I wouldn't use anything but 
ulaw\alaw.  The Bells can compete on price and will if they have to.  Where 
they CAN'T compete is quality.  If there were something better than 711, I'd 
offer that.  Well, there is 722, but not many things support it.


----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com


----- Original Message ----- 
From: <asterisk-users-request at lists.digium.com>
To: <asterisk-users at lists.digium.com>
Sent: Thursday, February 02, 2006 2:52 PM
Subject: Asterisk-Users Digest, Vol 19, Issue 19


> Send Asterisk-Users mailing list submissions to
> asterisk-users at lists.digium.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.digium.com/mailman/listinfo/asterisk-users
> or, via email, send a message with subject or body 'help' to
> asterisk-users-request at lists.digium.com
>
> You can reach the person managing the list at
> asterisk-users-owner at lists.digium.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Asterisk-Users digest..."
>
>
> Today's Topics:
>
>   1. 5,000 concurrent calls system rollout question (Vic)
>   2. How to handle "provider UNREACHABLE" in the dialplan?
>      (Ronald Wiplinger)
>   3. delaying "answer" for a number of rings or an amount of time
>      (Brian J. Murrell)
>   4. RE: 5,000 concurrent calls system rollout question
>      (Michael Loftis)
>   5. Re: 5,000 concurrent calls system rollout question
>      (Michael Loftis)
>   6. RE: Directed Call Pickup (Alex Barnes)
>   7. Re: ISDN Eicon Diva Server V-BRI (Bartosz Jozwiak)
>   8. RE: RE: 5, 000 concurrent calls system rollout question
>      (William Boehlke)
>   9. Re: ISDN Eicon Diva Server V-BRI (Jens Vagelpohl)
>  10. Re: RE: Rewind MusicOnHold? (Dan Journo)
>  11. Re: ISDN Eicon Diva Server V-BRI (Armin Schindler)
>  12. Agents, queues and zombies (Steve Rawlings)
>  13. Fw: Agents, queues and zombies (Steve Rawlings)
>  14. Re: ISDN Eicon Diva Server V-BRI (Armin Schindler)
>  15. Re: OT O'Reilly Asterisk TFOT (James Ronald)
>  16. Re: Blocked Callerid (pdhales at optusnet.com.au)
>  17. Re: fax possibilities (pdhales at optusnet.com.au)
>  18. Re: RE: Rewind MusicOnHold? (Dan Journo)
>  19. RE: OT O'Reilly Asterisk TFOT (Michael Collins)
>  20. Re: OT O'Reilly Asterisk TFOT (Mark Phillips)
>  21. RE: Anyone know a good ITSP in Canada that supports*?
>      (Technical Support)
>  22. Slightly OT: OpenPBX.org and Freeswitch (Michael Collins)
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 02 Feb 2006 12:17:03 -0700
> From: Michael Loftis <mloftis at wgops.com>
> Subject: RE: [Asterisk-Users] 5,000 concurrent calls system rollout
> question
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> <asterisk-users at lists.digium.com>
> Message-ID: <376DE673C9E840767FBB0EA6 at dhcp-2-206.wgops.com>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
>
>
> --On February 3, 2006 3:56:21 AM +0900 Vic <svictor at yahoo.co.jp> wrote:
>
>>
>> Hi, Joash,
>>
>> thank you for your email. I was very relieved to hear that someone was
>> already doing this.
>>
>> Can you please tell me more about your test? Why did you test it in a
>> first place?
>>
>> For me, we need to come up with a system that needs to:
>>
>> 1. Handle 5,000 inbound SIP calls
>>
>> 2. offer IVR capability
>>
>> 3. Billing
>
> You'd probably have to do some of your own work on this.  * makes 'CDR'
> records but...well...you have to be careful how you do your scripts if you
> want legible/useable CDRs.  There are some apps out there though that will
> process and do some sort of billing for CDRs not sure of what where.
>
>>
>> I thought that Asterisk would be up to the task, but, I am not sure as
>> to:
>>
>> 1. How many servers should I consider? 4? 10? Obviously, we will be
>> talking about probably core Xeon servers if this is what we need.
>
> I'd say atleast 10....maybe more...depending wholly on codec/transcoding
> and amount of IVR scripting.
>
>>
>> 2. How hard would it be to implement?
>
> Well...since your not well versed with *, and you're having trouble
> understanding the difference between a protocol and a codec, it might be
> really difficult for you.  You might want to farm it out.  There are a LOT
> of * consultancies out there now.  If you can get up to speed on asterisk
> pretty quickly and the various protocols and codecs then it's not
> impossible.  The kicker is all the management/maintenance UI's and such.
> But you might be able to use something like Signates sigMAN (never used it
> or their products).
>
>>
>> 3. How bad is g729 quality?
>>
>> 4. IVR : if the call is SIP, can we do prompts without transcoding?
>
> You're confusing protocols with codec's here again.  SIP is not a codec.
> That said if your SIP client is using GSM and there are GSM prompts
> available then the asterisk playback functions will use the GSM encoded
> prompts.
>
> Earlier you'd mentioned using POTS lines coming in/out.  If you're
> gatewaying 5k POTS lines you'll need a lot of machines.  Because you'll be
> doing  a lot of transcoding POTS is ulaw or alaw (depending on where in 
> the
> world you are) and unless you use (uncompressed) ulaw or alaw on your SIP
> clients (very unlikely scenario) you'll be transcoding to/from GSM. G.729,
> or whatever you're using.
>
>>
>> Any other suggestions that you might have would really be appreciated.
>>
>>
>>
>>
>>
>>  Joash Herbrink <Joash.Herbrink at Kahuna.nl> wrote:
>>
>>
>>
>> I have tested an asterisk server with over 5000 concurrent calls.
>>
>> The system setup was a P4 HT 3Ghz, 4 Gb RAM, and 1 gbps Ethernet
>> connection on a cisco 3560 switch.
>>
>>
>>
>> This works, but puts some serious stresses on the system.
>>
>> Why don't u considered using g.729 codec, this will at least lower the
>> bandwidth consumption significantly, and, you can overcome the CPU
>> resource issue by just using a server grade multi CPU xeon server.
>>
>>
>>
>> I would never the less still connect the system via 2 ethernet
>> connections, just for some redundancy, as mentioned before in this
>> thread.
>>
>>
>>
>> Bandwidth should be about 24 kbps (half duplex) per call
>>
>>
>>
>> So, 5000 * 24 is roughly 120 mbps, so a gigabit Ethernet should do just
>> fine.
>>
>>
>>
>> Joash
>>
>>
>>
>> -----Original Message-----
>> From: asterisk-users-bounces at lists.digium.com
>> [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Dustin
>> Wildes
>> Sent: Wednesday, February 01, 2006 8:54 AM
>> To: Asterisk Users Mailing List - Non-Commercial Discussion
>> Subject: Re: [Asterisk-Users] 5,000 concurrent calls system rollout
>> question
>>
>>
>>
>> Dinesh Nair wrote:
>>
>>
>>
>>>
>>
>>>
>>
>>> On 02/01/06 09:29 Damon Estep said the following:
>>
>>>
>>
>>>> Ok, now lets go for 5000 of them. 160kbps*5000=800000kbps or 800mbps -
>>
>>>> full duplex.
>>
>>>>
>>
>>>> Have you ever seen a NIC or switch that can run GigE full duplex at 80%
>>
>>>> utilization and not at least start to fall apart?
>>
>>>
>>
>>>
>>
>>> additionally, 5000 simultaneous SIP calls at 20ms intervals will send,
>>
>>>
>>
>>> 5,000 * 50 * 2 = 500,000 packets per second (full duplex).
>>
>>>
>>
>>> not too many boxes can handle such packet load, in spite of the
>>
>>> relatively small packet sizes.
>>
>>>
>>
>>
>>
>> Why not bond multiple NICs together to do a load balance output?  Would
>>
>> provide redundancy as well.
>>
>>
>>
>> _______________________________________________
>>
>> --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
>>
>
>
>
> --
> "Genius might be described as a supreme capacity for getting its 
> possessors
> into trouble of all kinds."
> -- Samuel Butler
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 02 Feb 2006 12:18:20 -0700
> From: Michael Loftis <mloftis at wgops.com>
> Subject: Re: [Asterisk-Users] 5,000 concurrent calls system rollout
> question
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> <asterisk-users at lists.digium.com>
> Message-ID: <FD4E6028E03A2C0CE007FA3C at dhcp-2-206.wgops.com>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
>
>
> --On February 3, 2006 4:07:05 AM +0900 Vic <svictor at yahoo.co.jp> wrote:
>
>>
>> Hi,
>>
>> several of your mentioned signant as a viable option.
>>
>> Has anyone ever used them? Are there any reviews for their products?
>>
>> Did they just put together a lot of Asterisks into a large scale PC? (I
>> am still struggling with the concept)
>
> Well I've nebver used it but any single box solution is going to have to
> have custom hardware and some custom code in asterisk or asterisk channel
> module to run it.  A PC can't do echo cancellation on 5k channels.  Can't
> do codec on 5k channels.  It might be able to do (light/simple/short) IVR
> on 5k channels though.
>
>>
>> Thanks,
>>
>> Vic
>
>
>
> --
> "Genius might be described as a supreme capacity for getting its 
> possessors
> into trouble of all kinds."
> -- Samuel Butler
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 2 Feb 2006 11:21:08 -0800
> From: "William Boehlke" <william.boehlke at signate.com>
> Subject: RE: [Asterisk-Users] RE: 5, 000 concurrent calls system
> rollout question
> To: "'Asterisk Users Mailing List - Non-Commercial Discussion'"
> <asterisk-users at lists.digium.com>
> Message-ID: <20060202192110.7C61344C118 at relay2.r2.iad.emailsrvr.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
> Signate has claimed 5,000 streams, or 2,500 calls, on a single Telephony
> Server 5000. The throughput has little to do with Asterisk and a lot to do
> with hardware design and operating system tuning. Our very minor code
> changes were returned to the project last year.
>
> The benchmark we used to make that initial claim was flawed, however we 
> have
> since replicated the throughput in a different way to save our marketing
> bacon.
>
> How we actually achieve the throughput is our intellectual property but we
> have a number of customers who are scaling towards and past that traffic
> level.  One of these days we hope to be able to justify the very large fee
> Hammer wants to extract from us to produce a third party verification.
>
> In production environments, of course, systems do more than switch calls. 
> We
> think high volume system design using 32-bit systems of any kind is 
> complex,
> and it's difficult to replicate the volumes without actual customer 
> traffic
> - and by then it's too late. Where do you put voicemail? Where does the 
> IVR
> reside?
>
> When someone needs to switch 5,000 calls with Class 5 services we would
> specify a rack of servers. The good news is that it is one rack, not three
> of them, but we need more than Asterisk alone, great though it is, to make
> everything work.
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: asterisk-users-bounces at lists.digium.com
> [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of John Todd
> Sent: Wednesday, February 01, 2006 9:33 PM
> To: asterisk-users at lists.digium.com; asterisk-dev at lists.digium.com
> Subject: [Asterisk-Users] RE: 5, 000 concurrent calls system rollout
> question
>
>
>>Signate sells a single server that can get you to the call volumes you
> need.
>>
>>Paul Mahler
>><mailto:pmahler at signate.com>pmahler at signate.com
>>www.signate.com
>>
> [snip]
>
> Past conversations on this topic have generated quite a bit of
> controversy within the Asterisk development community, both publicly
> here on the list forums as well as in quite a few more quiet
> discussions with people who often do not post but have extensive
> operational experiences with Asterisk (most of whom monitor the -dev
> list and whose replies will be suited to that audience.)
>
> The subject of load on a single chassis is still the most contentious
> issue to date.  The Signate numbers of >5000 calls per chassis with
> RTP are impressive, and there are others who claim more vaguely of
> 1000, 2000, or more calls into a single P4 server (with or without
> media.)  Others say that there are inherent limits in the Asterisk
> code which prevent more than ~500 calls from being processed with RTP
> at any one time.  Opterons, FreeBSD, custom Linux loads, Solaris, and
> other operating systems or hardware have been offered as the magic
> bullets to increase call volumes.  Who knows? (1)  I will say that
> extraordinary claims demand extraordinary evidence, which has been
> pretty thin.  I believe that most large call processing facilities
> still run on distributed systems of some type, as was described in
> the primary thread of this discussion on -users. (2)
>
> I know that there are some projects towards testing Asterisk more
> rigorously to determine these numbers.  However, I would suggest that
> the community at large could benefit from a more open examination of
> high-end system claims immediately than these (better) long-term
> tests which are progressing slowly (if at all.)  Let's just look at
> the "maximum" numbers.  Running a big system? Selling a big system?
> Tell us about it, in detail.  What are the limits that have been hit?
> Be specific.  I keep seeing hand-waving, but no programmers have come
> forward to say "It won't work because of the way X is implemented in
> the file blah.c or libFOO."
>
> To make a bad analogy:  I don't want to see the street rods; I just
> want to see the top-fuel, rocket-powered dragsters on the line.  Any
> takers?  It sounds like Signate has a contender, but quite a few
> people have said that it's impossible without serious modifications
> to the code.  Others have claimed (publicly or privately) that they
> can match those numbers on different hardware.
>
> Here are the criteria:
>   - Any O/S
>   - An unmodified version of Asterisk from SVN (or CVS)
>       OR patches must be available for inspection, as per the GPL
>       OR you must be a Digium license-holder (patches can be secret)
>   - All calls are IAX2 or SIP (both in and out)
>   - No transcoding of any type is required
>   - All calls are G.711, 20ms OR 30ms packet size
>
> Documentation:
>   - All O/S documentation, kernel tricks, modules, hacks, patches, or
> configuration elements should be documented, but proprietary
> information need not be divulged if that is deemed "secret"
>   - Testing method must be reasonably documented
>   - Dialplans must be included
>   - SIP.conf files must be included
>   - All hardware must be fully described (part numbers required)
>
> TEST #1:
>    All media must be handled by the server.  This is for both legs of
> the call.  The "canreinvite=no" for SIP and "notransfer=yes" in IAX2
> must be set for all calls.
>
> TEST #2:
>    Media may or may not be handled by the server.  Native transfers
> should be allowed in both IAX2 and/or SIP.
>
>
> (1) I have heard various people saying that it is "impossible" for
> Asterisk to handle a large number of calls due to architectural
> issues (no, it's not just from the people that you'd "expect" to hear
> this from.)  I've not been able to validate this one way or the other
> recently.  I am interested to hear what the developer community has
> as a comment on this topic.  I have an Empirix Hammer system at my
> company, but honestly I just don't have the time to set it up to do
> testing due to day job time constraints...
>
> (2) There are so many ways to spread calls across an Asterisk array
> it makes my head spin, but the question STILL comes down to "how many
> calls can a single chassis handle?"  Even in a farm of servers, there
> has to be a numerator in that ratio.
>
> JT
>
> _______________________________________________
> --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
>
>
>