Hi Bruno,
sorry but what is the conclusion of your mail? Everybody who wants to offer pre-paid VoIP services should use Asterisk instead of SER? Or something else what I missed?
Nils
On Saturday 09 July 2005 21:38, Bruno Lopes F. Cabral wrote:
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
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers