[Serusers] Session-Timers for Prepaid

[Greger V. Teigre]

See inline.

Bruno Lopes F. Cabral 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.

This is not true. A reasonable setup will at least have rtpproxy on another 
server than ser. With mediaproxy you can do load balancing across multiple 
servers, so using rtpproxy or mediaproxy does not impact the scalability of 
your SER server.

> 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).

This is true. Currently there is no good open source solution for running 
multiple SERs.  I have in previous emails (2-3 months ago) defined in 
detailed the different approaches and there are many good discussions on 
this topic.  One simple solution will be to pick up the Path module recently 
submitted to the experimental CVS module and use it to implement routing of 
calls through the correct registration server.  I have this on my to-do list 
(set up a test scenario) and hope to include that (eventually) as an 
appendix to the ONsip Getting Started document, but I don't foresee this in 
the near future. However, I would appreciate reports on attempts of using 
Path module this way.

> 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?

As the media streams will not go through SER, the simultaneous calls measure 
is not really interesting.  The measure used is number of call setups per 
second (and possible with a mix of registration requests).  Your setup (how 
you authenticate and what kind of lookups and modules you use) will greatly 
impact the number of calls handled per second.  Anyway, the number is BIG, 
if you skip authentication and do just basic call setup.  You really need to 
stress test your own scenario:
http://www.pernau.at/kd/voip/bookmarks-sip-rtp-ua.html#siptestutility

> 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?

Well, you can do that. Make a module!  However, you should now that you are 
trying to make SER do something it was not intended to do.  It is intended 
to be a stateless, high-scalability SIP server. You can probably turn it 
into a stateful server by creating a module, but I'm sure you will want to 
only implement very specific functionalities.  Then people start asking: can 
I do this or that?

> 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).

Yes, you can make a module that will save info in the DB and then you can 
register functions that will be called on timers.  Does this make SER 
stateful? Nope.  You have just hacked a functionality that normally requires 
a stateful server.  On the other hand, once you have a module registering 
info, it can probably be used for other "hacks" too.
    BTW, acc module can be seen as the module registering stateful info. You 
just need a module that can be invoked on timers. It's just that in a SER 
perspective, storing stuff in a DB is not good enough (due to scalability). 
You will need to implement a cache, export functions for other modules to 
use etc... And another thing, the design of SER is to handle incoming 
requests and react "reactively".  A module should be able to submit a new 
message and create a new dialog, but you need to be careful not to mess of 
the dialog you are in...

g-)