14 Nov
2023
14 Nov
'23
3:30 p.m.
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)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services
Kamailio Advanced Training -- asipto.com
14 Nov
14 Nov
4:12 p.m.
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
- print_lib
- pua_xmpp
- ratelimit
- uid_auth_db
- uid_avp_db
- uid_domain
- uid_gflags
- uid_uri_db
- uri_db
- xmpp
- xprint
Cheers,
Daniel
5:10 p.m.
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
> - print_lib
> - pua_xmpp
> - ratelimit
> - uid_auth_db
> - uid_avp_db
> - uid_domain
> - uid_gflags
> - uid_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
16 Nov
16 Nov
12:13 p.m.
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(a)quobis.com | t: +34902999465
O mar., 14 de nov. de 2023 ás 13:51, Daniel-Constantin Mierla via sr-users
(<sr-users(a)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)
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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
7:52 p.m.
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.t…
-
https://www.kamailio.org/docs/modules/stable/modules/dialog.html#dialog.f.d…
-
https://www.kamailio.org/docs/modules/stable/modules/dialog.html#dlg.r.term…
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(a)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(a)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 (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services
Kamailio Advanced Training -- asipto.com
21 Nov
21 Nov
10:46 a.m.
Hi all,
Regarding call limit, *pipelimit* then. If ratelimit is an old
implementation of the pipelimit functionlity, more reasons to deprecate it.
For us, topic closed, cool, thanks!
Regarding call time control, *dialog* doesn't seem to be our target, since
if focuses on dialogs, and what we are referring is to all the dialogs...
So external script controlling the dialogs will work. In fact, it is what
*call_control* should do.
But, *call_control* refers to an external application (
http://cdrtool.ag-projects.com/contact/), maybe the protocol is documented
there (I didn't find it). The module needs a re-visit, but it uses an old
Kamailio protocol (as stated on the documentation), and it seems coupled to
OpenSips project... Seems too much effort to replace a simple script. So,
ok for us to deprecate it, maybe we can develop something new based on the
same concepts.
Thanks a lot for your time!
*Santiago Troncoso*
Product Manager @ Quobis
e: santiago.troncoso(a)quobis.com | t: +34902999465
O xov., 16 de nov. de 2023 ás 17:52, Daniel-Constantin Mierla (<
miconda(a)gmail.com>) escribiu:
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.t…
-
https://www.kamailio.org/docs/modules/stable/modules/dialog.html#dialog.f.d…
-
https://www.kamailio.org/docs/modules/stable/modules/dialog.html#dlg.r.term…
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(a)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)
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(a)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 (@ asipto.com)twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services
Kamailio Advanced Training -- asipto.com
366
days inactive
373
days old
5 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Santiago Troncoso -
Social Boh