20 Dec
2012
20 Dec
'12
9:17 a.m.
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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
20 Dec
20 Dec
9:25 a.m.
20 dec 2012 kl. 15:17 skrev Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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
- 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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
9:39 a.m.
On 12/20/12 3:25 PM, Olle E. Johansson wrote:
I think Ovidiu Sas looked at it when he split the rtpproxy out in
a
dedicated module.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
20 dec 2012 kl. 15:17 skrev Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
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.
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
> - 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(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 
10:13 a.m.
On Thu, Dec 20, 2012 at 9:39 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
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/…
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
- 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.
11:04 a.m.
On 12/20/12 4:13 PM, Ovidiu Sas wrote:
On Thu, Dec 20, 2012 at 9:39 AM, Daniel-Constantin
Mierla
<miconda(a)gmail.com> wrote:
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/…
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.
- 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.
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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
11:20 a.m.
On Thu, Dec 20, 2012 at 11:04 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
On 12/20/12 4:13 PM, Ovidiu Sas wrote:
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
On Thu, Dec 20, 2012 at 9:39 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
IIRC, ping_contact whas the extra functionality in nathelper:
http://sip-router.org/docbook/sip-router/branch/master/modules_s/nathelper/…
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.
>
> - 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.
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.
11:16 a.m.
New subject: kamailio-ser integration - db modules
20 dec 2012 kl. 16:13 skrev Ovidiu Sas <osas(a)voipembedded.com>om>:
On Thu, Dec 20, 2012 at 9:39 AM, Daniel-Constantin
Mierla
<miconda(a)gmail.com> wrote:
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/…
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
- 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.
11:20 a.m.
New subject: kamailio-ser integration - db modules
On 12/20/12 5:16 PM, Olle E. Johansson wrote:
20 dec 2012 kl. 16:13 skrev Ovidiu Sas
<osas(a)voipembedded.com>om>:
It is not the case here, modules_k/ldap does not have any relation to
database interface.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
On Thu, Dec 20, 2012 at 9:39 AM,
Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
IIRC, ping_contact whas the extra functionality in nathelper:
http://sip-router.org/docbook/sip-router/branch/master/modules_s/nathelper/…
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?
> -
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.
11:35 a.m.
New subject: db libraries
20 dec 2012 kl. 17:20 skrev Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
On 12/20/12 5:16 PM, Olle E. Johansson wrote:
Well, I changed the issue then - I'm curious on the difference...
/O
20 dec 2012 kl. 16:13 skrev Ovidiu Sas
<osas(a)voipembedded.com>om>:
It is not the case here, modules_k/ldap does not have any relation to database
interface. On Thu, Dec 20, 2012 at 9:39 AM,
Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
What's the difference between the db1 and db2 interface?
>> - 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/…
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 ...
11:38 a.m.
New subject: kamailio-ser integration - db modules
On Thu, Dec 20, 2012 at 11:20 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
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
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. 
2:52 p.m.
New subject: kamailio-ser integration - db modules
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(a)voipembedded.com> wrote:
On Thu, Dec 20, 2012 at 11:20 AM, Daniel-Constantin
Mierla
<miconda(a)gmail.com> wrote:
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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.
21 Dec
21 Dec
2:29 a.m.
New subject: kamailio-ser integration - db modules
20 dec 2012 kl. 20:52 skrev Jan Janak <jan(a)janakj.org>rg>:
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(a)voipembedded.com> wrote:
On Thu, Dec 20, 2012 at 11:20 AM,
Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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.
20 Dec
20 Dec
10:20 a.m.
On Thu, Dec 20, 2012 at 9:25 AM, Olle E. Johansson <oej(a)edvina.net> wrote:
Take a look at the ratelimit module:
http://sip-router.org/docbook/sip-router/branch/master/modules/ratelimit/ra…
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/xh…
I would love to see everything migrated to rpc.
-ovidiu
- 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 :-)
11:17 a.m.
20 dec 2012 kl. 16:20 skrev Ovidiu Sas <osas(a)voipembedded.com>om>:
On Thu, Dec 20, 2012 at 9:25 AM, Olle E. Johansson
<oej(a)edvina.net> wrote:
Take a look at the ratelimit module:
http://sip-router.org/docbook/sip-router/branch/master/modules/ratelimit/ra…
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/xh…
I would love to see everything migrated to rpc.
Thanks for the pointers, Ovidiu!
/O
- 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 :-)
12:28 p.m.
20 dec 2012 kl. 17:17 skrev "Olle E. Johansson" <oej(a)edvina.net>et>:
20 dec 2012 kl. 16:20 skrev Ovidiu Sas <osas(a)voipembedded.com>om>:
And the new module compiles!
Will test later...
/O
On Thu, Dec 20, 2012 at 9:25 AM, Olle E.
Johansson <oej(a)edvina.net> wrote:
Take a look at the ratelimit module:
http://sip-router.org/docbook/sip-router/branch/master/modules/ratelimit/ra…
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/xh…
I would love to see everything migrated to rpc.
Thanks for the pointers, Ovidiu! - 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 :-)
4208
days inactive
4209
days old
14 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Jan Janak -
Olle E. Johansson -
Ovidiu Sas