Hello,
most of the duplicated or ser-specific modules were sorted out at this time, next is the situation with the remaining ones.
A) modules that will be renamed using a prefix 'uid_', because they have a database schema using unique id instead of username and domain: - auth_db => uid_auth_db - avp_db => uid_avp_db - domain => uid_domain - gflags => uid_gflags (not documented, but this module loads so called ser global avps) - uri_db => uid_uri_db
B) modules to become obsolete with some work to be done - cpl-c - seems that giving a parameter with what user to be used for loading the cpl scripts will make k and s versions compatible - maxfwd - different names for config functions - nathelper - some extra functionality, not sure if can be kept completely - textops - seems to have some extra cfg functions - pike - has a rpc command - registrar/usrloc - avps stored per contact
C) modules to become obsolete, most probably without further work - permissions - different structures/database table internally, but all should be achieved using k version (data migration might be required)
D) modules that needs further investigations - rr - there seems to be some feature related to avps and record-route parameters/cookies - this module could be just renamed at the end (like rrs)
E) Sample modules, not for real use - they can be kept in this directory (modules_s[ample]) - print - print_lib
If anyone has comments regarding these remarks, reply here.
Cheers, Daniel
20 dec 2012 kl. 15:17 skrev Daniel-Constantin Mierla miconda@gmail.com:
Hello,
most of the duplicated or ser-specific modules were sorted out at this time, next is the situation with the remaining ones.
A) modules that will be renamed using a prefix 'uid_', because they have a database schema using unique id instead of username and domain:
- auth_db => uid_auth_db
- avp_db => uid_avp_db
- domain => uid_domain
- gflags => uid_gflags (not documented, but this module loads so called ser global avps)
- uri_db => uid_uri_db
Apart from trying to help people not to change their db schemas - are there any functionality differences. If it's only the schema I think we can kindly force a change for a major release and make these obsolete. I guess we just have to say "please" and duck. A major release should be able to change stuff, in my opinion. We've been maintaining dual code for many years to make migration to modules_k and modules easier.
B) modules to become obsolete with some work to be done
- cpl-c - seems that giving a parameter with what user to be used for loading the cpl scripts will make k and s versions compatible
- maxfwd - different names for config functions
- nathelper - some extra functionality, not sure if can be kept completely
Maybe Andreas can look into this, as there is a lot of work going on with nathelper and the new rtpproxy anyways.
- textops - seems to have some extra cfg functions
- pike - has a rpc command
I need to learn about this stuff, so I can take a first stab at porting the RPC command to modules_k. Time for xmas hacking.
I propably will regret that part of the mail :-)
/O
- registrar/usrloc - avps stored per contact
C) modules to become obsolete, most probably without further work
- permissions - different structures/database table internally, but all should be achieved using k version (data migration might be required)
D) modules that needs further investigations
- rr - there seems to be some feature related to avps and record-route parameters/cookies - this module could be just renamed at the end (like rrs)
E) Sample modules, not for real use - they can be kept in this directory (modules_s[ample])
- print_lib
If anyone has comments regarding these remarks, reply here.
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 12/20/12 3:25 PM, Olle E. Johansson wrote:
20 dec 2012 kl. 15:17 skrev Daniel-Constantin Mierla miconda@gmail.com:
Hello,
most of the duplicated or ser-specific modules were sorted out at this time, next is the situation with the remaining ones.
A) modules that will be renamed using a prefix 'uid_', because they have a database schema using unique id instead of username and domain:
- auth_db => uid_auth_db
- avp_db => uid_avp_db
- domain => uid_domain
- gflags => uid_gflags (not documented, but this module loads so called ser global avps)
- uri_db => uid_uri_db
Apart from trying to help people not to change their db schemas - are there any functionality differences. If it's only the schema I think we can kindly force a change for a major release and make these obsolete. I guess we just have to say "please" and duck. A major release should be able to change stuff, in my opinion. We've been maintaining dual code for many years to make migration to modules_k and modules easier.
There are some different functionalities (global avps, domain avps). The most important aspect is that there are dependencies between them, that's why some of them cannot be removed. I think it is fine to keep them for a while at least, eventually giving 1-2 development cycles to see the usage and ask people to move to the other alternatives if discarding is the preferred way or no maintainers are taking care of them.
B) modules to become obsolete with some work to be done
- cpl-c - seems that giving a parameter with what user to be used for loading the cpl scripts will make k and s versions compatible
- maxfwd - different names for config functions
- nathelper - some extra functionality, not sure if can be kept completely
Maybe Andreas can look into this, as there is a lot of work going on with nathelper and the new rtpproxy anyways.
I think Ovidiu Sas looked at it when he split the rtpproxy out in a dedicated module.
Cheers, Daniel
- textops - seems to have some extra cfg functions
- pike - has a rpc command
I need to learn about this stuff, so I can take a first stab at porting the RPC command to modules_k. Time for xmas hacking.
I propably will regret that part of the mail :-)
/O
- registrar/usrloc - avps stored per contact
C) modules to become obsolete, most probably without further work
- permissions - different structures/database table internally, but all should be achieved using k version (data migration might be required)
D) modules that needs further investigations
- rr - there seems to be some feature related to avps and record-route parameters/cookies - this module could be just renamed at the end (like rrs)
E) Sample modules, not for real use - they can be kept in this directory (modules_s[ample])
- print_lib
If anyone has comments regarding these remarks, reply here.
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On Thu, Dec 20, 2012 at 9:39 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
- nathelper - some extra functionality, not sure if can be kept
completely
Maybe Andreas can look into this, as there is a lot of work going on with nathelper and the new rtpproxy anyways.
I think Ovidiu Sas looked at it when he split the rtpproxy out in a dedicated module.
IIRC, ping_contact whas the extra functionality in nathelper: http://sip-router.org/docbook/sip-router/branch/master/modules_s/nathelper/n... I don't know how widely used is this functionality.
Maybe we should have a separate thread per module (in user mailing list to gather more imput) and see if it's worth merging the code or use only the k version.
Also, on a separate note, I saw the we have a few db2_[module]. I think it would make sense for these modules to rename them into [module]_db[1|2]. For example: ldap - we should have both versions under modules: - ldap_db1 - ldap_db2 Just a suggestion ...
-ovidiu
On 12/20/12 4:13 PM, Ovidiu Sas wrote:
On Thu, Dec 20, 2012 at 9:39 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
- nathelper - some extra functionality, not sure if can be kept
completely
Maybe Andreas can look into this, as there is a lot of work going on with nathelper and the new rtpproxy anyways.
I think Ovidiu Sas looked at it when he split the rtpproxy out in a dedicated module.
IIRC, ping_contact whas the extra functionality in nathelper: http://sip-router.org/docbook/sip-router/branch/master/modules_s/nathelper/n... I don't know how widely used is this functionality.
Maybe we should have a separate thread per module (in user mailing list to gather more imput) and see if it's worth merging the code or use only the k version.
I re-cc-ed the thread to users in case someone has comments to it.
Also, on a separate note, I saw the we have a few db2_[module]. I think it would make sense for these modules to rename them into [module]_db[1|2]. For example: ldap - we should have both versions under modules:
- ldap_db1
- ldap_db2
Just a suggestion ...
The type of the two ldap modules are different, modules_k/ldap is a connector to ldap server from configuration file, offering possibility to do ldap search queries from config.
The former modules_s/ldap (now db2_ldap) is a DB API v2 implementation driver module, so it can be used as a replacement for db_mysql (for example) when using some modules (such as db2_ops). I prefixed with db2_ to indicate that is not implementing DB API v1.
Cheers, Daniel
On Thu, Dec 20, 2012 at 11:04 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 12/20/12 4:13 PM, Ovidiu Sas wrote:
On Thu, Dec 20, 2012 at 9:39 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
- nathelper - some extra functionality, not sure if can be kept
completely
Maybe Andreas can look into this, as there is a lot of work going on with nathelper and the new rtpproxy anyways.
I think Ovidiu Sas looked at it when he split the rtpproxy out in a dedicated module.
IIRC, ping_contact whas the extra functionality in nathelper:
http://sip-router.org/docbook/sip-router/branch/master/modules_s/nathelper/n... I don't know how widely used is this functionality.
Maybe we should have a separate thread per module (in user mailing list to gather more imput) and see if it's worth merging the code or use only the k version.
I re-cc-ed the thread to users in case someone has comments to it.
Also, on a separate note, I saw the we have a few db2_[module]. I think it would make sense for these modules to rename them into [module]_db[1|2]. For example: ldap - we should have both versions under modules:
- ldap_db1
- ldap_db2
Just a suggestion ...
The type of the two ldap modules are different, modules_k/ldap is a connector to ldap server from configuration file, offering possibility to do ldap search queries from config.
The former modules_s/ldap (now db2_ldap) is a DB API v2 implementation driver module, so it can be used as a replacement for db_mysql (for example) when using some modules (such as db2_ops). I prefixed with db2_ to indicate that is not implementing DB API v1.
I see now. I failed to check the README file. Now it's all clear. Maybe we should have the module as db_ldap with a TODO item in the README (about implementing db API v1). I think it will be more clear. And then we cam move ldap module from modules_k to modules.
-ovidiu
20 dec 2012 kl. 16:13 skrev Ovidiu Sas osas@voipembedded.com:
On Thu, Dec 20, 2012 at 9:39 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
- nathelper - some extra functionality, not sure if can be kept
completely
Maybe Andreas can look into this, as there is a lot of work going on with nathelper and the new rtpproxy anyways.
I think Ovidiu Sas looked at it when he split the rtpproxy out in a dedicated module.
IIRC, ping_contact whas the extra functionality in nathelper: http://sip-router.org/docbook/sip-router/branch/master/modules_s/nathelper/n... I don't know how widely used is this functionality.
Maybe we should have a separate thread per module (in user mailing list to gather more imput) and see if it's worth merging the code or use only the k version.
Also, on a separate note, I saw the we have a few db2_[module]. I think it would make sense for these modules to rename them into [module]_db[1|2]. For example: ldap - we should have both versions under modules:
- ldap_db1
- ldap_db2
Just a suggestion ...
What's the difference between the db1 and db2 interface?
/O
On 12/20/12 5:16 PM, Olle E. Johansson wrote:
20 dec 2012 kl. 16:13 skrev Ovidiu Sas osas@voipembedded.com:
On Thu, Dec 20, 2012 at 9:39 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
- nathelper - some extra functionality, not sure if can be kept
completely
Maybe Andreas can look into this, as there is a lot of work going on with nathelper and the new rtpproxy anyways.
I think Ovidiu Sas looked at it when he split the rtpproxy out in a dedicated module.
IIRC, ping_contact whas the extra functionality in nathelper: http://sip-router.org/docbook/sip-router/branch/master/modules_s/nathelper/n... I don't know how widely used is this functionality.
Maybe we should have a separate thread per module (in user mailing list to gather more imput) and see if it's worth merging the code or use only the k version.
Also, on a separate note, I saw the we have a few db2_[module]. I think it would make sense for these modules to rename them into [module]_db[1|2]. For example: ldap - we should have both versions under modules:
- ldap_db1
- ldap_db2
Just a suggestion ...
What's the difference between the db1 and db2 interface?
It is not the case here, modules_k/ldap does not have any relation to database interface.
Cheers, Daniel
20 dec 2012 kl. 17:20 skrev Daniel-Constantin Mierla miconda@gmail.com:
On 12/20/12 5:16 PM, Olle E. Johansson wrote:
20 dec 2012 kl. 16:13 skrev Ovidiu Sas osas@voipembedded.com:
On Thu, Dec 20, 2012 at 9:39 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
- nathelper - some extra functionality, not sure if can be kept
completely
Maybe Andreas can look into this, as there is a lot of work going on with nathelper and the new rtpproxy anyways.
I think Ovidiu Sas looked at it when he split the rtpproxy out in a dedicated module.
IIRC, ping_contact whas the extra functionality in nathelper: http://sip-router.org/docbook/sip-router/branch/master/modules_s/nathelper/n... I don't know how widely used is this functionality.
Maybe we should have a separate thread per module (in user mailing list to gather more imput) and see if it's worth merging the code or use only the k version.
Also, on a separate note, I saw the we have a few db2_[module]. I think it would make sense for these modules to rename them into [module]_db[1|2]. For example: ldap - we should have both versions under modules:
- ldap_db1
- ldap_db2
Just a suggestion ...
What's the difference between the db1 and db2 interface?
It is not the case here, modules_k/ldap does not have any relation to database interface.
Well, I changed the issue then - I'm curious on the difference...
/O
On Thu, Dec 20, 2012 at 11:20 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
What's the difference between the db1 and db2 interface?
It is not the case here, modules_k/ldap does not have any relation to database interface.
Any database module db_[DatabaseType] implements an API. SER was using one API and opensips/kamailio a different API (and therefore today we have version 1 and 2). All db modules in the stable release are supporting both APIs. The new db ldap module has support only for the SER API version. The API is documented in each lib/srdb[1|]/*.h header files.
The ldap module from ser is completely different than ldap module from kamailio (despite the fact that both are using the same name). It's the same with the dialog module. Check the README file for each.
Hope this brings a little bit of light :)
-ovidiu
The database API version 2 (originating from SER) is an evolved version of the database API that Kamailio has (version 1), they both share a common ancestor.
The main motivation for designing a new API was to make it possible to integrate SER with non-SQL based databases. The general idea was that SER would include an API that would enable it to execute general queries on the database server. Any results those queries produce would get converted into AVPs. SER modules that depend on data obtained from the database would then work primarily with those AVPs. You could also process those AVPs directly in the configuration file in the routing logic.
In theory this enables the integration of SER with in-memory and no-SQL based databases. I have tested this with LDAP (hence the generic LDAP database driver), Cassandra, and other (proprietary) database engines. One could also implement RADIUS support in form of a database connector via this API, but I never found the time to do that.
The version 2 of the database API is, unfortunately, not backwards compatible with version 1. That's because version 1 assumes that all database queries are directly mapped to corresponding SQL statements. Version 2 is a bit more general and does not assume SQL.
Although we also did a number of changes to the database schema used by SER around the same time, those schema changes are not related to the new database API. Version 2 of the database API does not require schema changes per se and it should work fine with the database schema used by Kamailio.
Somewhere in the process of changing the database code I also added support for pre-compiled statements to the MySQL connector module, in fact the module uses them by default for all database queries. I thought this might improve performance of the MySQL connector module (which it does under certain circumstances), but in practice it only makes things more complicated. Properly configured SQL query cache on the database server works even better in terms of performance.
-Jan
On Thu, Dec 20, 2012 at 11:38 AM, Ovidiu Sas osas@voipembedded.com wrote:
On Thu, Dec 20, 2012 at 11:20 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
What's the difference between the db1 and db2 interface?
It is not the case here, modules_k/ldap does not have any relation to database interface.
Any database module db_[DatabaseType] implements an API. SER was using one API and opensips/kamailio a different API (and therefore today we have version 1 and 2). All db modules in the stable release are supporting both APIs. The new db ldap module has support only for the SER API version. The API is documented in each lib/srdb[1|]/*.h header files.
The ldap module from ser is completely different than ldap module from kamailio (despite the fact that both are using the same name). It's the same with the dialog module. Check the README file for each.
Hope this brings a little bit of light :)
-ovidiu
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
20 dec 2012 kl. 20:52 skrev Jan Janak jan@janakj.org:
The database API version 2 (originating from SER) is an evolved version of the database API that Kamailio has (version 1), they both share a common ancestor.
The main motivation for designing a new API was to make it possible to integrate SER with non-SQL based databases. The general idea was that SER would include an API that would enable it to execute general queries on the database server. Any results those queries produce would get converted into AVPs. SER modules that depend on data obtained from the database would then work primarily with those AVPs. You could also process those AVPs directly in the configuration file in the routing logic.
In theory this enables the integration of SER with in-memory and no-SQL based databases. I have tested this with LDAP (hence the generic LDAP database driver), Cassandra, and other (proprietary) database engines. One could also implement RADIUS support in form of a database connector via this API, but I never found the time to do that.
The version 2 of the database API is, unfortunately, not backwards compatible with version 1. That's because version 1 assumes that all database queries are directly mapped to corresponding SQL statements. Version 2 is a bit more general and does not assume SQL.
Although we also did a number of changes to the database schema used by SER around the same time, those schema changes are not related to the new database API. Version 2 of the database API does not require schema changes per se and it should work fine with the database schema used by Kamailio.
Somewhere in the process of changing the database code I also added support for pre-compiled statements to the MySQL connector module, in fact the module uses them by default for all database queries. I thought this might improve performance of the MySQL connector module (which it does under certain circumstances), but in practice it only makes things more complicated. Properly configured SQL query cache on the database server works even better in terms of performance.
Jan, Thank you for the extensive feedback and tutorial!
This should be copied to the wiki.
/O
-Jan
On Thu, Dec 20, 2012 at 11:38 AM, Ovidiu Sas osas@voipembedded.com wrote:
On Thu, Dec 20, 2012 at 11:20 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
What's the difference between the db1 and db2 interface?
It is not the case here, modules_k/ldap does not have any relation to database interface.
Any database module db_[DatabaseType] implements an API. SER was using one API and opensips/kamailio a different API (and therefore today we have version 1 and 2). All db modules in the stable release are supporting both APIs. The new db ldap module has support only for the SER API version. The API is documented in each lib/srdb[1|]/*.h header files.
The ldap module from ser is completely different than ldap module from kamailio (despite the fact that both are using the same name). It's the same with the dialog module. Check the README file for each.
Hope this brings a little bit of light :)
-ovidiu
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On Thu, Dec 20, 2012 at 9:25 AM, Olle E. Johansson oej@edvina.net wrote:
- pike - has a rpc command
I need to learn about this stuff, so I can take a first stab at porting the RPC command to modules_k. Time for xmas hacking.
I probably will regret that part of the mail :-)
Take a look at the ratelimit module: http://sip-router.org/docbook/sip-router/branch/master/modules/ratelimit/rat... There are simple examples there on getting and setting values.
And if you add an rpc command and it just pops up on the xhttp_rpc interface, then it's a first good step :) http://sip-router.org/docbook/sip-router/branch/master/modules/xhttp_rpc/xht...
I would love to see everything migrated to rpc.
-ovidiu
20 dec 2012 kl. 16:20 skrev Ovidiu Sas osas@voipembedded.com:
On Thu, Dec 20, 2012 at 9:25 AM, Olle E. Johansson oej@edvina.net wrote:
- pike - has a rpc command
I need to learn about this stuff, so I can take a first stab at porting the RPC command to modules_k. Time for xmas hacking.
I probably will regret that part of the mail :-)
Take a look at the ratelimit module: http://sip-router.org/docbook/sip-router/branch/master/modules/ratelimit/rat... There are simple examples there on getting and setting values.
And if you add an rpc command and it just pops up on the xhttp_rpc interface, then it's a first good step :) http://sip-router.org/docbook/sip-router/branch/master/modules/xhttp_rpc/xht...
I would love to see everything migrated to rpc.
Thanks for the pointers, Ovidiu!
/O
20 dec 2012 kl. 17:17 skrev "Olle E. Johansson" oej@edvina.net:
20 dec 2012 kl. 16:20 skrev Ovidiu Sas osas@voipembedded.com:
On Thu, Dec 20, 2012 at 9:25 AM, Olle E. Johansson oej@edvina.net wrote:
- pike - has a rpc command
I need to learn about this stuff, so I can take a first stab at porting the RPC command to modules_k. Time for xmas hacking.
I probably will regret that part of the mail :-)
Take a look at the ratelimit module: http://sip-router.org/docbook/sip-router/branch/master/modules/ratelimit/rat... There are simple examples there on getting and setting values.
And if you add an rpc command and it just pops up on the xhttp_rpc interface, then it's a first good step :) http://sip-router.org/docbook/sip-router/branch/master/modules/xhttp_rpc/xht...
I would love to see everything migrated to rpc.
Thanks for the pointers, Ovidiu!
And the new module compiles!
Will test later...
/O
-
Daniel-Constantin Mierla -
Jan Janak -
Olle E. Johansson -
Ovidiu Sas