[Serusers] Session-Timers for Prepaid

[Nils Ohlmeier]

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 at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers