[asterisk-users] SER/OpenSER,
I Finally Get It.............General Observation
JR Richardson
jmr.richardson at gmail.com
Tue Apr 24 14:43:36 MST 2007
Sorry if this hit the list twice, sent out yesterday, but didn't see it show up.
Hi All,
Can Asterisk be used as a SIP proxy, blah, blah, blah???
I've glanced over questions like this through the years, with a good idea on
what a SIP proxy is and what Asterisk is and IS NOT. I never really took
the time to lab-up SER and test drive it to see what advantages might be
gained from using it to front-end an Asterisk Cluster. In fact, I pride
myself on using Asterisk (alone) to its fullest ability to accomplish my
clustering and scaling goals. As an ITSP, adding customers, means racking
and stacking more Asterisk servers and gel them into the Cluster, no
problem. Adding PSTN connectivity would mean the same for the most
part..............here lays the conundrum.
I didn't have a good way to load balance the PSTN connections, and as
embarrassing as it is, Cisco Call Manager connections as well. So after
growing and scaling a bit, I realized I would need a load balancer for
non-asterisk SIP originating trunks coming into the Asterisk Cluster. After
a few minutes of pondering, said to myself, I can really use a good SIP
proxy with a round-robin load balancing mechanism. SER came to mind.
I always wanted to mock up SER and test it out, but never had a strong need
for it. After reading the some documents and such 'Hello World', literally
2 to 3 hours of researching and about an hour of lab server setup and SER
installation, I had phones registered and talking. Once the foundation was
laid, I loaded the dispatcher module in SER and with a bit of trial and
error with the config file, had load balancing fired up across 4 Asterisk
servers. Not exactly what I was looking for, SER has random load balancing,
so the distribution across the cluster varied widely.
I checked out OpenSER (a SER fork), which has a newer dispatcher module,
incorporating a round-robin load balancer and skip-to-the-next-server
fail-over mechanism. This actually performed more to my liking. A couple
of little bugs, the last entry in the dispatcher.list is skipped over for
some reason and the first entry in the dispatcher.list is called twice (can
someone tell me why this is or tell me how to fix it?). Now for the test:
I created a call-loop, like a stress test, between an Asterisk server acting
as a PSTN Gateway device and 4 Asterisk servers in a Cluster arrangement
load balanced by OpenSER in between. Since OpenSER is just a proxy, no
audio was used. I initiated 80 calls to SER which proxy'ed the calls to the
4 Asterisk servers, in turn those 80 distributed calls initiated 80 more
calls which looped back to OpenSER, and back to the 4 Asterisk servers
generating 80 more calls and so on. The calls continued till the Asterisk
servers pretty much cratered, couldn't open any more files, SIP resources
unavailable, 1300+ sip channels open, proc utilization 50%+............all
in a matter of a few second.
OpenSER took all that 5 Asterisk servers could handle and never winced,
didn't break a sweat, did not even breach 2% proc utilization.
I ran this test more than 10 times, each concluding with reloading all 5
Asterisk servers to re-gain control. I did not reload Open SER once.
Two things come out of this testing, first and foremost, I am still and will
always be a true Astriholic; and second, I can't seem to break OpenSER and
if you can't break-em, join-em.
Can I use OpenSER as a voicemail server, blah, blah, blah???
JR
JR Richardson
Engineering for the Masses
More information about the asterisk-users
mailing list