On 22 Nov 2008, at 00:06, Michael Collins wrote: >> Date: Fri, 21 Nov 2008 16:20:28 -0600 >> From: Terry Wilson <[EMAIL PROTECTED]> >> Subject: Re: [asterisk-users] Large Asterisk installarions (~10, > 000 >> extensions), preferably at universities >> To: Asterisk Users Mailing List - Non-Commercial Discussion >> <asterisk-users@lists.digium.com> >> Message-ID: <[EMAIL PROTECTED]> >> 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. _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users