[SR-Dev] Conversion of kamailio modules

[Daniel-Constantin Mierla]

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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>   

-- 
Daniel-Constantin Mierla
http://www.asipto.com