9 Jul
2005
9 Jul
'05
9:38 p.m.
Hello there
nice feedback, Iqbal, thanks!
Iqbal wrote:
Ser and prepaid, I think its hard to have a tigh 100%
solution for
prepaid, just because SER is not designed as a B2BUA, which asterisk
has included, but if u look at the additional cost incurred to scale
upto 10000 users, in terms of bandwidth and hardware,
everyone talks about how SER scales compared to asterisk but
I must confess I have some doubts on that matter. most setups
shown here in the list use any of rtpproxy or mediaproxy,
which in turn will cause traffic to pass through SER host
and drop scale accordling.
the solutions to that (as I've read on the list) are not so
"easy" setups like non standard LVS patches, multiple SER
instances with some sort of memory and/or database contact
replications among other creative arrangements that are not
included in default SER, nor easy to install - or free (as
in beer).
so, how many calls a "decent" server (P4, 2.xGHz, 2GB RAM)
running SER plus mediaproxy or rtpproxy can really handle?
1k simultaneous calls? and how many users connected? 2k?
anyone willing to give a shot, perhaps from experience?
For prepay and SER what u need is to know the time,
and then send
disconnect.The time u can do a basic systems from acc, unmatched
INVITES, session-timers etc etc, the disconnect use sipsak..however
the latter I just cannot get to work well. I think ser could use a
tighter module which would disconnect.
most of the time the setups shown here are also stateless,
which would at first glance increase the scalability of
SER solution. as I stated above, the scalability with
mediaproxy and rtpproxy drops hard, but forgetting about
that for a minute, how about running SER statefull? to
include some info for every running call in memory (or
database) and periodically (a thread maybe) runnning the
call list and sending BYEs to both parties would eat so
much memory or processor power that would prevent one to
use that solution at all, in our "decent" server setup?
please don't take me wrong, I really think SER is a great
server, and it is far less complex to install than the
full featured asterisk (thanks to the well written docs
and ONSIP's iniciative), but the advantages of having control
of calls and callers seems a reasonable adition to me,
mainly of course if it can be enabled to who needs it
while mantaining the nice low footprint for the ones that
want to run SER on their OPENWRT boxes.
(I really liked the proposed solution of saving call info
and periodically sending the BYEs through fifo interface.
if it could be compiled as a module and/or perhaps a
socket interface to a running "call server" instead of
exec'ing the (external) perl routine at each call would
increase scalability a lot while satisfing all of us
that needs call control but don't know how/want to
integrate an external/alien B2BUA to our SER setups).
Cheers,
!3runo
from Brazil