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