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.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda