10 Jul
2005
10 Jul
'05
12:45 a.m.
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(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers