Hello,
during the Kamailio Developers Meeting 2023 in Dusseldorf that took place last week, it was proposed to obsolete modules that seem to be unmaintained and no activity about them was noticed during the past years. It is quite some overhead in packaging them and trying to keep them compiling when they have external dependencies, therefore such step should spare some resources in the future.
The list (see below) was built based on the options of those present at the meeting, now we want to discuss it on the larger communities of developers and users. If you are using any of these modules or you think any of them worth keeping, reply with the names of the modules that you want to be kept.
The proposed action is to relocate the obsoleted modules to a new git repository "kamailio-obsolete" to still keep some visibility to them and in the eventually of future interest on any of them, it can be reintroduced in the main repository.
Next is the initial list of modules proposed to be considered obsolete:
- app_java - app_lua_sr - app_mono - app_python - app_sqlang - auth_identity - call_control - db2_ldap - db2_ops - db_cassandra - db_perldvdb - dnssec - domainpolicy - h350 - mediaproxy - osp - peering - print - print_lib - pua_xmpp - ratelimit - uid_auth_db - uid_avp_db - uid_domain - uid_gflags - uid_uri_db - uri_db - xmpp - xprint
Cheers, Daniel
I use uri_db module and the does_uri_exist() function to know if a user exist or not.
I don't know if there is other function I can use with the same task
Regards
--- I'm SoCIaL, MayBe
El 14/11/2023 a las 7:30 a. m., Daniel-Constantin Mierla via sr-users escribió:
Hello,
during the Kamailio Developers Meeting 2023 in Dusseldorf that took place last week, it was proposed to obsolete modules that seem to be unmaintained and no activity about them was noticed during the past years. It is quite some overhead in packaging them and trying to keep them compiling when they have external dependencies, therefore such step should spare some resources in the future.
The list (see below) was built based on the options of those present at the meeting, now we want to discuss it on the larger communities of developers and users. If you are using any of these modules or you think any of them worth keeping, reply with the names of the modules that you want to be kept.
The proposed action is to relocate the obsoleted modules to a new git repository "kamailio-obsolete" to still keep some visibility to them and in the eventually of future interest on any of them, it can be reintroduced in the main repository.
Next is the initial list of modules proposed to be considered obsolete:
- app_java
- app_lua_sr
- app_mono
- app_python
- app_sqlang
- auth_identity
- call_control
- db2_ldap
- db2_ops
- db_cassandra
- db_perldvdb
- dnssec
- domainpolicy
- h350
- mediaproxy
- osp
- peering
- print_lib
- pua_xmpp
- ratelimit
- uid_auth_db
- uid_avp_db
- uid_domain
- uid_gflags
- uid_uri_db
- uri_db
- xmpp
- xprint
Cheers, Daniel
Good spot, actually uri_db was not proposed to be obsoleted, my mistake on copy&paste the group of uid* modules.
Cheers, Daniel
On 14.11.23 14:12, Social Boh wrote:
I use uri_db module and the does_uri_exist() function to know if a user exist or not.
I don't know if there is other function I can use with the same task
Regards
I'm SoCIaL, MayBe
El 14/11/2023 a las 7:30 a. m., Daniel-Constantin Mierla via sr-users escribió:
Hello,
during the Kamailio Developers Meeting 2023 in Dusseldorf that took place last week, it was proposed to obsolete modules that seem to be unmaintained and no activity about them was noticed during the past years. It is quite some overhead in packaging them and trying to keep them compiling when they have external dependencies, therefore such step should spare some resources in the future.
The list (see below) was built based on the options of those present at the meeting, now we want to discuss it on the larger communities of developers and users. If you are using any of these modules or you think any of them worth keeping, reply with the names of the modules that you want to be kept.
The proposed action is to relocate the obsoleted modules to a new git repository "kamailio-obsolete" to still keep some visibility to them and in the eventually of future interest on any of them, it can be reintroduced in the main repository.
Next is the initial list of modules proposed to be considered obsolete:
- app_java
- app_lua_sr
- app_mono
- app_python
- app_sqlang
- auth_identity
- call_control
- db2_ldap
- db2_ops
- db_cassandra
- db_perldvdb
- dnssec
- domainpolicy
- h350
- mediaproxy
- osp
- peering
- print_lib
- pua_xmpp
- ratelimit
- uid_auth_db
- uid_avp_db
- uid_domain
- uid_gflags
- uid_uri_db
- xmpp
- xprint
Cheers, Daniel
Hi community,
We are discussing internally the deprecated modules. Some are referred to control traffic limits, we are in favor to keep the field clean and remove deprecated not-updated modules. So in order to cover the following use cases, which modules do you recommend? how are you covering it currently?
- Limit call duration. Drop a call after some configurable time. call_control https://www.kamailio.org/docs/modules/devel/modules/call_control.html covered it, but it does not work properly, so usually is covered by external scripting. - Control of the burst requests, e.g.: a REGISTER avalanche after network recovery. Use pike https://www.kamailio.org/docs/modules/devel/modules/pike.html and control it via script? ratelimit https://www.kamailio.org/docs/modules/devel/modules/ratelimit.html was doing something similar... seems to be covered by pipelimit https://www.kamailio.org/docs/modules/devel/modules/pipelimit.html...
So, we are not looking to keep them, the simpler and cleaner project, the best for all. So we are in favor to deprecated them. But, what alternatives do you recommend?
Thanks in advance!
*Santiago Troncoso*
Product Manager @ Quobis http://www.quobis.com/ e: santiago.troncoso@quobis.com | t: +34902999465
O mar., 14 de nov. de 2023 ás 13:51, Daniel-Constantin Mierla via sr-users (sr-users@lists.kamailio.org) escribiu:
Hello,
during the Kamailio Developers Meeting 2023 in Dusseldorf that took place last week, it was proposed to obsolete modules that seem to be unmaintained and no activity about them was noticed during the past years. It is quite some overhead in packaging them and trying to keep them compiling when they have external dependencies, therefore such step should spare some resources in the future.
The list (see below) was built based on the options of those present at the meeting, now we want to discuss it on the larger communities of developers and users. If you are using any of these modules or you think any of them worth keeping, reply with the names of the modules that you want to be kept.
The proposed action is to relocate the obsoleted modules to a new git repository "kamailio-obsolete" to still keep some visibility to them and in the eventually of future interest on any of them, it can be reintroduced in the main repository.
Next is the initial list of modules proposed to be considered obsolete:
- app_java
- app_lua_sr
- app_mono
- app_python
- app_sqlang
- auth_identity
- call_control
- db2_ldap
- db2_ops
- db_cassandra
- db_perldvdb
- dnssec
- domainpolicy
- h350
- mediaproxy
- osp
- peering
- print_lib
- pua_xmpp
- ratelimit
- uid_auth_db
- uid_avp_db
- uid_domain
- uid_gflags
- uid_uri_db
- uri_db
- xmpp
- xprint
Cheers, Daniel
-- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy and Development Services Kamailio Advanced Training -- asipto.com
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hello,
On 16.11.23 10:13, Santiago Troncoso wrote:
Hi community,
We are discussing internally the deprecated modules. Some are referred to control traffic limits, we are in favor to keep the field clean and remove deprecated not-updated modules. So in order to cover the following use cases, which modules do you recommend? how are you covering it currently?
- Limit call duration. Drop a call after some configurable time. call_control https://www.kamailio.org/docs/modules/devel/modules/call_control.html covered it, but it does not work properly, so usually is covered by external scripting.
I haven't used this module so far, is the protocol for interacting with the external application documented somewhere?
Usually is the dialog module that can terminate a call, it has embedded options to set call duration, but can be also triggered externally via RPC:
- https://www.kamailio.org/docs/modules/stable/modules/dialog.html#dialog.p.ti... - https://www.kamailio.org/docs/modules/stable/modules/dialog.html#dialog.f.dl... - https://www.kamailio.org/docs/modules/stable/modules/dialog.html#dlg.r.termi...
The cnxcc module does also something related to call control, but I haven't used it either.
- Control of the burst requests, e.g.: a REGISTER avalanche after network recovery. Use pike https://www.kamailio.org/docs/modules/devel/modules/pike.html and control it via script? ratelimit https://www.kamailio.org/docs/modules/devel/modules/ratelimit.html was doing something similar... seems to be covered by pipelimit https://www.kamailio.org/docs/modules/devel/modules/pipelimit.html...
Indeed pipelimit is the one to be used instead of ratelimit, the former started from the later, bringing in database support and pipes that can be created on the fly. The functionality of "queues" can be just done using if conditions on method in the routing blocks.
So, we are not looking to keep them, the simpler and cleaner project, the best for all. So we are in favor to deprecated them. But, what alternatives do you recommend?
Keeping call_control is fine if provides something that is uses. pipelimit should be much better than ratelimit, but if people still use ratelimit, can be kept as well. The scope is to remove what is not used, sometime activity around modules is low because nothing needs to be done for them, the proposed list might not reflect the reality, the discussion here aims to discover that.
Cheers, Daniel
O mar., 14 de nov. de 2023 ás 13:51, Daniel-Constantin Mierla via sr-users (sr-users@lists.kamailio.org) escribiu:
Hello, during the Kamailio Developers Meeting 2023 in Dusseldorf that took place last week, it was proposed to obsolete modules that seem to be unmaintained and no activity about them was noticed during the past years. It is quite some overhead in packaging them and trying to keep them compiling when they have external dependencies, therefore such step should spare some resources in the future. The list (see below) was built based on the options of those present at the meeting, now we want to discuss it on the larger communities of developers and users. If you are using any of these modules or you think any of them worth keeping, reply with the names of the modules that you want to be kept. The proposed action is to relocate the obsoleted modules to a new git repository "kamailio-obsolete" to still keep some visibility to them and in the eventually of future interest on any of them, it can be reintroduced in the main repository. Next is the initial list of modules proposed to be considered obsolete: - app_java - app_lua_sr - app_mono - app_python - app_sqlang - auth_identity - call_control - db2_ldap - db2_ops - db_cassandra - db_perldvdb - dnssec - domainpolicy - h350 - mediaproxy - osp - peering - print - print_lib - pua_xmpp - ratelimit - uid_auth_db - uid_avp_db - uid_domain - uid_gflags - uid_uri_db - uri_db - xmpp - xprint Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com <http://asipto.com>) twitter.com/miconda <http://twitter.com/miconda> -- linkedin.com/in/miconda <http://linkedin.com/in/miconda> Kamailio Consultancy and Development Services Kamailio Advanced Training -- asipto.com <http://asipto.com> __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-
Daniel-Constantin Mierla -
Santiago Troncoso -
Social Boh