Hello,
I started converting kamailio modules yesterday, in the first step I'm trying to see if I can make them compile and load. I haven't tried to verify if they really work. Currently I can compile the following kamailio modules:
acc auth auth_db auth_diameter auth_radius alias_db benchmark db_unixodbc carrierroute cfgutils db_berkeley db_flatstore db_mysql db_oracle db_postgres db_text db_unixodbc diversion exec h350 maxfwd misc_radius mi_xmlrpc pdt peering permissions pike regex rr sanity siputils speeddial sqlops statistics uri_db userblacklist xcap_client xlog
There is 93 modules in kamailio repository, that means I can currently compile about 40% of them on the sip-router core.
Most of the modules above required some manual changes, but not exteremely complicated. The biggest issue is extra stuff in kamalio core which is missing (or present on other modules) in the sip-router core. I created a new shared library called libkcore and whenever I find that something is missing in sip-router, I take it from kamailio and put it in the library.
It's not that nice because there will be duplicated code, but I think we should first try to make everything compile and then we can think about how to organize the code better.
Jan.
Hello,
On 02/25/2009 11:34 AM, Jan Janak wrote:
Hello,
I started converting kamailio modules yesterday, in the first step I'm trying to see if I can make them compile and load. I haven't tried to verify if they really work. Currently I can compile the following kamailio modules:
acc auth auth_db auth_diameter auth_radius alias_db benchmark db_unixodbc carrierroute cfgutils db_berkeley db_flatstore db_mysql db_oracle db_postgres db_text db_unixodbc diversion exec h350 maxfwd misc_radius mi_xmlrpc pdt peering permissions pike regex rr sanity siputils speeddial sqlops statistics uri_db userblacklist xcap_client xlog
There is 93 modules in kamailio repository, that means I can currently compile about 40% of them on the sip-router core.
Most of the modules above required some manual changes, but not exteremely complicated. The biggest issue is extra stuff in kamalio core which is missing (or present on other modules) in the sip-router core. I created a new shared library called libkcore
this looks ok for first phase.
I think the modules with more work to do are the ones depending on TM. There were some API changes there, also some new features.
How to deal with these new features? Make a new module that sits on top of TM? IMO, tm gets bigger and bigger, as more features are pushed there, but probably would make sense to pull out those that are not commonly used. So we keep TM as light as possible, taking care of transaction management, relaying ... Code such as exported pseudo-variables (referring mainly to $T_req/$T_rpl) can be placed in a new module - tmx - tm eXtensions. Just an idea... opinions?
Cheers, Daniel
and whenever I find that something is missing in sip-router, I take it from kamailio and put it in the library.
It's not that nice because there will be duplicated code, but I think we should first try to make everything compile and then we can think about how to organize the code better.
Jan.
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Jan Janak writes:
Most of the modules above required some manual changes, but not exteremely complicated. The biggest issue is extra stuff in kamalio core which is missing (or present on other modules) in the sip-router core. I created a new shared library called libkcore and whenever I find that something is missing in sip-router, I take it from kamailio and put it in the library.
jan,
did lcr compilation fail due to tm binding or something else?
regarding kamailio's tm module, i recently added these two functions to it:
{"t_load_contacts", (cmd_function)t_load_contacts, 0, 0, 0, REQUEST_ROUTE | FAILURE_ROUTE}, {"t_next_contacts", (cmd_function)t_next_contacts, 0, 0, 0, REQUEST_ROUTE | FAILURE_ROUTE},
would it be possible to add them also to sip-router tm module?
also domain module was missing from your list. is it because mi commands?
-- juha
On 25-02 21:00, Juha Heinanen wrote:
Jan Janak writes:
Most of the modules above required some manual changes, but not exteremely complicated. The biggest issue is extra stuff in kamalio core which is missing (or present on other modules) in the sip-router core. I created a new shared library called libkcore and whenever I find that something is missing in sip-router, I take it from kamailio and put it in the library.
jan,
did lcr compilation fail due to tm binding or something else?
Yes, due to changes in tm module api.
regarding kamailio's tm module, i recently added these two functions to it:
{"t_load_contacts", (cmd_function)t_load_contacts, 0, 0, 0, REQUEST_ROUTE | FAILURE_ROUTE}, {"t_next_contacts", (cmd_function)t_next_contacts, 0, 0, 0, REQUEST_ROUTE | FAILURE_ROUTE},
would it be possible to add them also to sip-router tm module?
Yes, I remember we exchanged some emails about this, we can surely add them.
also domain module was missing from your list. is it because mi commands?
This is again related to tm. Domain module failed to compile because of a the route type test in uri_host_local. This can be easily rewritten for sip-router, but I was just too tired to look it up yesterday and thus posponed fixing the module.
Jan.
On 02/25/2009 09:00 PM, Juha Heinanen wrote:
[...] is it because mi commands?
MI API was ported to sip-router. It resides as libkmi (sip-router/lib/kmi). I tested and works fine -- however, the mi transports modules need some changes, as forking new processes is a bit different in sip-router.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Jan Janak -
jh＠tutpro.com