[asterisk-users] Large Asterisk installarions (~10, 000 extensions), preferably at universities

Tim Panton thp at westhawk.co.uk
Sat Nov 22 06:28:50 CST 2008


On 22 Nov 2008, at 00:06, Michael Collins wrote:

>> Date: Fri, 21 Nov 2008 16:20:28 -0600
>> From: Terry Wilson <twilson at digium.com>
>> Subject: Re: [asterisk-users] Large Asterisk installarions (~10,
> 000
>> 	extensions), preferably at universities
>> To: Asterisk Users Mailing List - Non-Commercial Discussion
>> 	<asterisk-users at lists.digium.com>
>> Message-ID: <E03AA2A5-4850-4340-A50D-8DF93E1FBF91 at digium.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>>> Yehavi Bourvine wrote:
>>>
>>>> OK, but I still did not get a reply to my original question: Why
>>>> using
>>>> SIP registrar in front of Asterisk and not simply use bare
> Astersik?
>>>> can't it handle the load? (remember - in my case it doesn't handle
>>>> the
>>>> RTP, only signalling). Can't it handle so much registrations? (I am
>>>> using realtime DB, it is has any relevance).
>>>
>>> My experience has shown that using a dedicated registrar for large
>>> installs is more effective;  it doesn't tie up resources on the
>>> Asterisk
>>> box with all those registration refreshes, for one.  A product built
>>> to
>>> be a high-throughput standalone registrar will handle the
> concurrency
>>> requirements and perform better.
>>
>> I've looked at doing various things to chan_sip to improve signaling
>> performance (hash tables for call lookups, etc.)  I gave up when I
>> realized that the overhead of handling the RTP was so far above the
>> overhead of processing SIP signaling that it didn't really matter
>> much.  The only reason I have ever had to use a SIP registrar  
>> (OpenSER
>> in my case) was if I needed to load balance calls across multiple
>> asterisk servers.  If most of the phones are not separated by a NAT
>> from Asterisk (as would be the case in something like a University
>> network), the registration timeout could be set to a relatively high
>> value w/o causing any problems which would cut down on some of the  
>> SIP
>> traffic from registrations.
>>
>> In fact, I just ran some tests using SIPp and w/o any audio, using
>> realtime w/ 10k accounts I can register 100/second while doing 10
>> calls/second.  If you are looking just at registrations every 15
>> minutes or so, that is 90k devices that could register to asterisk.
>> This was using 1.6.0.1 on my little HP amd64 development box--not
>> anything near the kind of machine that you would probably install  
>> in a
>> large installation.  Asterisk just gets faster and faster.  Some of
>> the "it isn't good at x" stuff comes from experiences with older
>> releases.
>
> In a HA and/or high volume scenario I worry about stuff like this that
> has been in tree since 1.0 or earlier and is in 1.6, channel.c lines
> 3825~3828:
>
>        /* XXX This is a seriously wacked out operation.  We're
> essentially putting the guts of
>           the clone channel into the original channel.  Start by
> killing off the original
>           channel's backend.   I'm not sure we're going to keep this
> function, because
>           while the features are nice, the cost is very high in terms
> of pure nastiness. XXX */
>
> That's not something I want in my high-end, high-capacity,
> high-availability production system!

Actually that's exactly the kind of comment I _do_ want to see in an  
opensource
platform. It is honest, open and an encouragement to others to think  
of a better fix.

Discourage poor coding, critique the
design etc  - but please don't discourage this kind of commenting, it  
is the kind
of thing that helps one find a bug _infinitely_ faster that you could  
without the
clue the original author left for you.

Tim.





More information about the asterisk-users mailing list