[Serusers] Session-Timers for Prepaid

[Iqbal]

The mediaproxy part is used for natting problems, and this can be
separated out from the proxy itself, however there is still overhead I
guess if you want the entire solution put together. If you don't have
nat problems and you get ur customers to use external IP's then there
is a huge benefit.

the lvs part of it is about having multiple redundant ser's working
together, and doing some sort of load balancing,

Because ser is designed as a proxy, which makes it inherently different
from asterisk, it shouldn't/cant be compared to asterisk. Asterisk is
actually easier (I find :-)) than ser.

A plugin module like u suggest would be great, maybe not even make it
part of ser, just a module, I know people will say use some other b2bua,
but the module with a tighter intergration in ser is better.

The way I have it currently is ser sitting infron of everything else, i.e
the gateways and asterisk (which in my case doesnt do pstn, but i just
use it for pbx stuff)

The mediaproxy and all can then all be pulled onto sep servers as and
when required.

SER + asterisk I think is very powerful, since ser can handle all the
message stuff and let asterisk do the pbx part. This way users who dont
need mediaproy, dont use it (some saving), those who do not need
features of asterisk, dont, (again saving), and those who need both,
well I have to accept that I take a hit, but why take a hit all the time.

If I have 10000 users, out of that 1% is corporate using all pbx stuff,
and the rest 9900 50% use nat 50% dont, I have a 50% saving, which means
if I can fine tune my billing, I get prepay,postpay, with a few lost
cents here and there. I concede it will never be perfect, but I am
designing something for the 21st century, and my thoughts are the
billing by minute will go, and flat rate per month any country to any
country will be the way, so fo rthe short term, I am patching :-)

Iqbal


On 7/9/2005, "Bruno Lopes F. Cabral" <bruno at openline.com.br> wrote:

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