Guys,
We've developed a module called lcr_rate.so, which acts on top of the
existing lcr.so module and performs real cost-based least cost routing.
It's quite Sipwise specific, so I wanted to ask whether there is any
interest in - or it makes sense to - pushing it to upstream.
The module is really simple from its functionality point of view. You
call load_gws() as usual from the existing lcr.so module, and the
lcr_rate.so module takes the resulting AVP and reorders the entries
based on the cost per gateway:
loadmodule "lcr.so"
modparam("lcr", "gw_uri_avp", "$avp(s:lcr_uri_list)")
loadmodule "lcr_rate.so"
modparam("lcr_rate", "gw_uri_avp", "$avp(s:lcr_uri_list)")
load_gws(...);
lcr_rate("$rU", "$rd");
while(...) { next_gw(); ... }
The actual cost per destination is calculated using libswrate, which we
will publish as GPL along with the module.
However, the whole inner workings are specific to our sip:provider
CE/PRO platforms though, which means we are using the lcr_gw.flags
column to store the gateway id from another table, which maps to gateway
groups, which in turn reference to a billing profile id where the actual
fees per destination are attached to. So to get any practical use out of
this, you'd need to use the Sipwise provisioning and billing databases,
or adapt your backend to reflect that.
A way out of this lock-in would be to use diameter or radius to get the
actual cost for a call, as this might be a standardized interface to do
so (IMS?), but we currently don't use that. However, the module could
later be modified to take advantage of that, once a diameter client is
available in the main branch.
If you say it doesn't make any sense at all (which might be likely),
we're going to provide the source on our github page for people
interested in it.
Any comments/opinions?
Andreas
Hello,
based on community interaction, development, package distributions and
documentation maintenance in the recent years, the default flavour has
been switched now to 'kamailio'.
As written in my previous email, we started the last phase to complete
the integration between kamailio-ser, aiming to get to a unique database
schema and set of modules in maximum 6 months.
Kamailio is the most spread and popular flavour, presented in many
linux/unix distributions, being the one released and packaged
periodically. So it will stay as main flavour, the one officially
released by the project. Those that want can take the sources and build
their own flavour, as the support in Makefile system is kept.
Once the integration is finished, the flavour system will just set the
application name, nothing else. From the open source project
perspective, the resources will be allocated only on releasing under the
main/default flavour (Kamailio).
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hello,
we plan to start the last phase of integration between kamailio and ser.
After about 4 years with same source code tree, there is still some
overhead caused by several duplicated modules. Following the decision to
go on with the most developed components and absorb the missing features
from the duplicates, kamailio modules are those that will stay (move to
modules/ eventually) and get updates when needed. We used same decision
to keep the core and makefile system from ser, adding to it what was
extra in kamailio.
I present next a summary of what is planned to happen:
1) Modules from modules_s/ that will be simply moved to modules/ because
there is no conflict at all:
- avp, avp_db, db_ops, eval, mangler, print, print_lib
2) Modules from modules_s/ that will be renamed and moved modules/
because it is mainly only conflict of name, but not in the backend
(e.g., database):
- auth_db => auth_dbattrs - because it uses (attribute,value) style
to store subscriber profiles, which can be a preferred alternative for
many out there
- ldap => db2_ldap - it is a DB APIv2 connector to ldap server
- bdb => db2_bdb - it is a DB APIv2 connector to berkeley db (to be
double-checked)
- xlog => xprintf - it uses %spec to print log messages with all
the code inside the module - the only reason not discarding it and stick
only to modules_k/xlog for the moment is because it is used from other
modules, otherwise modules_k/xlog has more features (e.g., syslog
facility, color printing, a.s.o)
3) Modules from modules_s/ that will be removed, after absorbing some
extra features:
- usrloc/registrar => get the ability to store AVPs per contact
(modules_k is more advanced in features, like path/gruu/partial outbound
support, publish presence states, etc.)
- several modules must be reviewed: acc*, radius*, permissions,
pike, gflags, options, timer
4) Modules from modules_s/ that will be removed, by moving to obsolete/
directory
- the rest of them from modules_s/, like dialog, xcap, cpl-c,
presence_b2b, dispatcher, dbtext, domain, etc.
The categories and their content are not nailed down, it is the purpose
of this discussion to see if something was overlooked.
We hope to end this process in max 6 months time - after that will be a
unique database schema and a unique set of modules. Flavour system in
the Makefile will stay just for letting people choose easier the name of
binary, otherwise everything will be the same (e.g., what is compiled,
installed, etc).
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda