Hello,
starting to continue the discussions here on mailing lists about some of the approached topics during the last IRC meeting -- there will be couple of them.
The one now is about finding and deploying a ranking/rating system that could eventually help community members to make decisions easier in regard to what components to use in their voip systems.
The need was exemplified by user verticelo with the dificulty to decide what KEMI scripting language to use. While maintaining all the app_xyz are expected to be easy, at least I know that for those I created, the arguments were also from the perspective of the community. Like what others are using, so one can expect good assistance, hints and share of knowledge via community forums. This can be also extended to related tools, like what people use for shared IP high availability of kamailio, preferred database servers, ...
This email is to ask if those that didn't participate to IRC devel meeting find such system useful and, if there is a positive feedback, is anyone aware of some OSS that we can deploy on kamailio.org for such purpose? It should be something that allows posting a topic (title and short description) along with a list of answers/options (each can be again like a title and short description) and provide a way to rate the options (like, thumbs up, starts, ...), eventually allowing also comments for each option. I guess it sounds a bit like stackoverflow ...
Being users related, the email is sent only to sr-users, let's keep the discussion on this mailing list.
Cheers, Daniel
Hi,
A few off-the-cuff thoughts, in no particular order:
1. Kamailio does have hundreds of modules of all kinds, and some sort of guide for which ones to use when, or some other schema which would serve to provide some conceptual organisation for the modules, is probably a desirable documentation objective.
2. I am nevertheless wary of any system which purports to "rank" or "rate" components.
One obvious reason is that popularity isn't a very good metric for whether something is appropriate for or applicable to a particular purpose. There is a reason the expression "degenerated into a popularity contest" exists in our industry. This is all the more true given (arguably) Kamailio's somewhat unique status as a "toolkit" or a "framework" for building certain kinds of systems and services; it means some of the most useful components in many scenarios might be either obscure, or so broadly general that a highly fact-dependent / situation-specific logic of its relationship to a given scenario is hard to tease out. Would you "recommend" the TM module? Is it widely used? :-)
This goes to another, more general problem with ranking components, and that is that the module ecosystem is a wildly eclectic bag of things of very different scope. Without a more rigid preconceived taxonomy to create the right mental categories, meaningful comparisons between modules are difficult to draw, as would be theoretically required for some kind of ranking or any system which purports to raise the profile of some components over others.
Kamailio modules fall into at least a few identifiable categories--this is just a half-hearted improvisational stab at it, and probably not very nuanced:
a. "Essential" / "core" - while these are technically modules, their feature set is so universal and critical to most non-trivial Kamailio implementations that they are substantially equivalent to "core" functionality. Modules like 'rr', 'tm' and 'pv' clearly fall into this category. One cannot really do anything worthy of remark with Kamailio without them, excluding some exotic cases.
b. Broad and holistic systems - complete categories of broad SIP server functionality implemented in more or less one module (usrloc + registrar, presence/pua, auth*, dispatcher, etc.);
c. Dependencies of other higher-level modules - the relationship of 'usrloc' to 'registrar' is suitably described by this; if you're using 'usrloc', you're almost certainly using 'registrar', and there are really no meaningful standalone uses of 'usrloc', nor does it expose any route script functions. At the same time, the list of things one may wish to interrogate via RPC/management interfaces are split between 'usrloc' and 'registrar' in ways that make sense to a programmer but which users might find arbitrary. In any case, do you give 'usrloc' a "thumbs up"? What does that even mean? :-)
Some modules are hybrids; they have some standalone functionality but are most commonly inputs into a higher-level usage, such as 'xhttp' and its relationship to 'jsonrpcs', or the various presence_* or pua_* subcomponents, some of the auth_* components, ims_*, etc.
d. Pure API dependencies of other modules - these expose internal APIs used by other modules and provide no standalone functionality others. One can debate whether 'usrloc' falls into this category, but certainly, 'dmq' is a good example of this, as are the various 'db_*' connectors, and maybe 'keepalive'.
e. Niche programmatic functionality - 'htable', 'cfgutils', 'jansson', 'async', etc. This category entails additional programmatic constructs relevant to the "software engineering" aspect of writing config/route script or how processing is done, but do not provide any external services or interfaces as such.
f. Broadly environmental - subtly alter the overall way that SIP messages are processed, or add support for new kinds of transports, etc. This would include 'tls', 'ws', 'outbound', and the 'topo{h,s}' modules.
g. Language / API / interpreter connectors - 'app_*' modules.
h. Highly specific functionality - most other modules fall into this. But some of the functionality is fairly high-level, e.g. 'rtpengine', while others are more low-level and closer to category E, such as 'mqueue'.
Anyway, the point here is that I don't think a vehicle to provide community guidance about which components to use, or which would purport to rank them somehow, can be meaningfully separated from the equally vital need to create some kind of taxonomy of modules or, more generally, adequate categories of thought within which such conversations should take place. Kamailio documentation lacks a clear and distinct "metaphysics" in this sense.
-- Alex
On Thu, Mar 14, 2019 at 09:55:41AM +0100, Daniel-Constantin Mierla wrote:
Hello,
starting to continue the discussions here on mailing lists about some of the approached topics during the last IRC meeting -- there will be couple of them.
The one now is about finding and deploying a ranking/rating system that could eventually help community members to make decisions easier in regard to what components to use in their voip systems.
The need was exemplified by user verticelo with the dificulty to decide what KEMI scripting language to use. While maintaining all the app_xyz are expected to be easy, at least I know that for those I created, the arguments were also from the perspective of the community. Like what others are using, so one can expect good assistance, hints and share of knowledge via community forums. This can be also extended to related tools, like what people use for shared IP high availability of kamailio, preferred database servers, ...
This email is to ask if those that didn't participate to IRC devel meeting find such system useful and, if there is a positive feedback, is anyone aware of some OSS that we can deploy on kamailio.org for such purpose? It should be something that allows posting a topic (title and short description) along with a list of answers/options (each can be again like a title and short description) and provide a way to rate the options (like, thumbs up, starts, ...), eventually allowing also comments for each option. I guess it sounds a bit like stackoverflow ...
Being users related, the email is sent only to sr-users, let's keep the discussion on this mailing list.
Cheers, Daniel
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com Kamailio Advanced Training - Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
By way of further thought:
Perhaps a component-orientated view is not the correct one here. It almost sounds like what is being sought is a kind of "cookbook of Kamailio patterns"[1], if you like. This answers a lot of questions that also capture preferences about third-party FOSS componentry, such as:
"Should I do HA failover with VRRP or Heartbeat?"
"Is Kamailio + PostgreSQL a stable combination for a high-volume registrar?"
"Are there pitfalls to DMQ dialog replication?"
"What is the best way to build a load balancer with failover and gateway monitoring?"
etc.
-- Alex
[1] We use the term "cookbook" differently in this project, but this usage is closer to the commonplace conventional one.
On Thu, Mar 14, 2019 at 08:35:15AM -0400, Alex Balashov wrote:
Hi,
A few off-the-cuff thoughts, in no particular order:
- Kamailio does have hundreds of modules of all kinds, and some sort of
guide for which ones to use when, or some other schema which would serve to provide some conceptual organisation for the modules, is probably a desirable documentation objective.
- I am nevertheless wary of any system which purports to "rank" or
"rate" components.
One obvious reason is that popularity isn't a very good metric for whether something is appropriate for or applicable to a particular purpose. There is a reason the expression "degenerated into a popularity contest" exists in our industry. This is all the more true given (arguably) Kamailio's somewhat unique status as a "toolkit" or a "framework" for building certain kinds of systems and services; it means some of the most useful components in many scenarios might be either obscure, or so broadly general that a highly fact-dependent / situation-specific logic of its relationship to a given scenario is hard to tease out. Would you "recommend" the TM module? Is it widely used? :-)
This goes to another, more general problem with ranking components, and that is that the module ecosystem is a wildly eclectic bag of things of very different scope. Without a more rigid preconceived taxonomy to create the right mental categories, meaningful comparisons between modules are difficult to draw, as would be theoretically required for some kind of ranking or any system which purports to raise the profile of some components over others.
Kamailio modules fall into at least a few identifiable categories--this is just a half-hearted improvisational stab at it, and probably not very nuanced:
a. "Essential" / "core" - while these are technically modules, their feature set is so universal and critical to most non-trivial Kamailio implementations that they are substantially equivalent to "core" functionality. Modules like 'rr', 'tm' and 'pv' clearly fall into this category. One cannot really do anything worthy of remark with Kamailio without them, excluding some exotic cases.
b. Broad and holistic systems - complete categories of broad SIP server functionality implemented in more or less one module (usrloc + registrar, presence/pua, auth*, dispatcher, etc.);
c. Dependencies of other higher-level modules - the relationship of 'usrloc' to 'registrar' is suitably described by this; if you're using 'usrloc', you're almost certainly using 'registrar', and there are really no meaningful standalone uses of 'usrloc', nor does it expose any route script functions. At the same time, the list of things one may wish to interrogate via RPC/management interfaces are split between 'usrloc' and 'registrar' in ways that make sense to a programmer but which users might find arbitrary. In any case, do you give 'usrloc' a "thumbs up"? What does that even mean? :-)
Some modules are hybrids; they have some standalone functionality but are most commonly inputs into a higher-level usage, such as 'xhttp' and its relationship to 'jsonrpcs', or the various presence_* or pua_* subcomponents, some of the auth_* components, ims_*, etc.
d. Pure API dependencies of other modules - these expose internal APIs used by other modules and provide no standalone functionality others. One can debate whether 'usrloc' falls into this category, but certainly, 'dmq' is a good example of this, as are the various 'db_*' connectors, and maybe 'keepalive'.
e. Niche programmatic functionality - 'htable', 'cfgutils', 'jansson', 'async', etc. This category entails additional programmatic constructs relevant to the "software engineering" aspect of writing config/route script or how processing is done, but do not provide any external services or interfaces as such.
f. Broadly environmental - subtly alter the overall way that SIP messages are processed, or add support for new kinds of transports, etc. This would include 'tls', 'ws', 'outbound', and the 'topo{h,s}' modules.
g. Language / API / interpreter connectors - 'app_*' modules.
h. Highly specific functionality - most other modules fall into this. But some of the functionality is fairly high-level, e.g. 'rtpengine', while others are more low-level and closer to category E, such as 'mqueue'.
Anyway, the point here is that I don't think a vehicle to provide community guidance about which components to use, or which would purport to rank them somehow, can be meaningfully separated from the equally vital need to create some kind of taxonomy of modules or, more generally, adequate categories of thought within which such conversations should take place. Kamailio documentation lacks a clear and distinct "metaphysics" in this sense.
-- Alex
On Thu, Mar 14, 2019 at 09:55:41AM +0100, Daniel-Constantin Mierla wrote:
Hello,
starting to continue the discussions here on mailing lists about some of the approached topics during the last IRC meeting -- there will be couple of them.
The one now is about finding and deploying a ranking/rating system that could eventually help community members to make decisions easier in regard to what components to use in their voip systems.
The need was exemplified by user verticelo with the dificulty to decide what KEMI scripting language to use. While maintaining all the app_xyz are expected to be easy, at least I know that for those I created, the arguments were also from the perspective of the community. Like what others are using, so one can expect good assistance, hints and share of knowledge via community forums. This can be also extended to related tools, like what people use for shared IP high availability of kamailio, preferred database servers, ...
This email is to ask if those that didn't participate to IRC devel meeting find such system useful and, if there is a positive feedback, is anyone aware of some OSS that we can deploy on kamailio.org for such purpose? It should be something that allows posting a topic (title and short description) along with a list of answers/options (each can be again like a title and short description) and provide a way to rate the options (like, thumbs up, starts, ...), eventually allowing also comments for each option. I guess it sounds a bit like stackoverflow ...
Being users related, the email is sent only to sr-users, let's keep the discussion on this mailing list.
Cheers, Daniel
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com Kamailio Advanced Training - Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Agreed Alex, I think a cookbook with recommendations would be very useful to help get people started.
In the documentation, perhaps if there are a lot of stale/unused modules they could be moved to a different section as well or flagged with an icon so people know they are not a preferred choice for new/modern setups.
I suppose there are a number of different areas where a lot of people make decisions where one could just offer simple guidance such as:
Database: MySQL
Failover: Heartbeat
Kemi: app_python3
RTP: RTPEngine
I understand that not everyone would agree but would save new users a lot of work in comparing and trying to figure out what to choose for new projects. These recommendations would of course change with time as things evolve.
Regarding the rating system, not sure how to capture meaningful data that conveys the reality from the community. I think some of the veterans in the project who know what people use would provide more meaningful insight rather than a click drive vote or similar.
// Samuel
________________________________ From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Alex Balashov abalashov@evaristesys.com Sent: Thursday, March 14, 2019 14:19 To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] RFC: rating - ranking system for community
By way of further thought:
Perhaps a component-orientated view is not the correct one here. It almost sounds like what is being sought is a kind of "cookbook of Kamailio patterns"[1], if you like. This answers a lot of questions that also capture preferences about third-party FOSS componentry, such as:
"Should I do HA failover with VRRP or Heartbeat?"
"Is Kamailio + PostgreSQL a stable combination for a high-volume registrar?"
"Are there pitfalls to DMQ dialog replication?"
"What is the best way to build a load balancer with failover and gateway monitoring?"
etc.
-- Alex
[1] We use the term "cookbook" differently in this project, but this usage is closer to the commonplace conventional one.
On Thu, Mar 14, 2019 at 08:35:15AM -0400, Alex Balashov wrote:
Hi,
A few off-the-cuff thoughts, in no particular order:
- Kamailio does have hundreds of modules of all kinds, and some sort of
guide for which ones to use when, or some other schema which would serve to provide some conceptual organisation for the modules, is probably a desirable documentation objective.
- I am nevertheless wary of any system which purports to "rank" or
"rate" components.
One obvious reason is that popularity isn't a very good metric for whether something is appropriate for or applicable to a particular purpose. There is a reason the expression "degenerated into a popularity contest" exists in our industry. This is all the more true given (arguably) Kamailio's somewhat unique status as a "toolkit" or a "framework" for building certain kinds of systems and services; it means some of the most useful components in many scenarios might be either obscure, or so broadly general that a highly fact-dependent / situation-specific logic of its relationship to a given scenario is hard to tease out. Would you "recommend" the TM module? Is it widely used? :-)
This goes to another, more general problem with ranking components, and that is that the module ecosystem is a wildly eclectic bag of things of very different scope. Without a more rigid preconceived taxonomy to create the right mental categories, meaningful comparisons between modules are difficult to draw, as would be theoretically required for some kind of ranking or any system which purports to raise the profile of some components over others.
Kamailio modules fall into at least a few identifiable categories--this is just a half-hearted improvisational stab at it, and probably not very nuanced:
a. "Essential" / "core" - while these are technically modules, their feature set is so universal and critical to most non-trivial Kamailio implementations that they are substantially equivalent to "core" functionality. Modules like 'rr', 'tm' and 'pv' clearly fall into this category. One cannot really do anything worthy of remark with Kamailio without them, excluding some exotic cases.
b. Broad and holistic systems - complete categories of broad SIP server functionality implemented in more or less one module (usrloc + registrar, presence/pua, auth*, dispatcher, etc.);
c. Dependencies of other higher-level modules - the relationship of 'usrloc' to 'registrar' is suitably described by this; if you're using 'usrloc', you're almost certainly using 'registrar', and there are really no meaningful standalone uses of 'usrloc', nor does it expose any route script functions. At the same time, the list of things one may wish to interrogate via RPC/management interfaces are split between 'usrloc' and 'registrar' in ways that make sense to a programmer but which users might find arbitrary. In any case, do you give 'usrloc' a "thumbs up"? What does that even mean? :-)
Some modules are hybrids; they have some standalone functionality but are most commonly inputs into a higher-level usage, such as 'xhttp' and its relationship to 'jsonrpcs', or the various presence_* or pua_* subcomponents, some of the auth_* components, ims_*, etc.
d. Pure API dependencies of other modules - these expose internal APIs used by other modules and provide no standalone functionality others. One can debate whether 'usrloc' falls into this category, but certainly, 'dmq' is a good example of this, as are the various 'db_*' connectors, and maybe 'keepalive'.
e. Niche programmatic functionality - 'htable', 'cfgutils', 'jansson', 'async', etc. This category entails additional programmatic constructs relevant to the "software engineering" aspect of writing config/route script or how processing is done, but do not provide any external services or interfaces as such.
f. Broadly environmental - subtly alter the overall way that SIP messages are processed, or add support for new kinds of transports, etc. This would include 'tls', 'ws', 'outbound', and the 'topo{h,s}' modules.
g. Language / API / interpreter connectors - 'app_*' modules.
h. Highly specific functionality - most other modules fall into this. But some of the functionality is fairly high-level, e.g. 'rtpengine', while others are more low-level and closer to category E, such as 'mqueue'.
Anyway, the point here is that I don't think a vehicle to provide community guidance about which components to use, or which would purport to rank them somehow, can be meaningfully separated from the equally vital need to create some kind of taxonomy of modules or, more generally, adequate categories of thought within which such conversations should take place. Kamailio documentation lacks a clear and distinct "metaphysics" in this sense.
-- Alex
On Thu, Mar 14, 2019 at 09:55:41AM +0100, Daniel-Constantin Mierla wrote:
Hello,
starting to continue the discussions here on mailing lists about some of the approached topics during the last IRC meeting -- there will be couple of them.
The one now is about finding and deploying a ranking/rating system that could eventually help community members to make decisions easier in regard to what components to use in their voip systems.
The need was exemplified by user verticelo with the dificulty to decide what KEMI scripting language to use. While maintaining all the app_xyz are expected to be easy, at least I know that for those I created, the arguments were also from the perspective of the community. Like what others are using, so one can expect good assistance, hints and share of knowledge via community forums. This can be also extended to related tools, like what people use for shared IP high availability of kamailio, preferred database servers, ...
This email is to ask if those that didn't participate to IRC devel meeting find such system useful and, if there is a positive feedback, is anyone aware of some OSS that we can deploy on kamailio.org for such purpose? It should be something that allows posting a topic (title and short description) along with a list of answers/options (each can be again like a title and short description) and provide a way to rate the options (like, thumbs up, starts, ...), eventually allowing also comments for each option. I guess it sounds a bit like stackoverflow ...
Being users related, the email is sent only to sr-users, let's keep the discussion on this mailing list.
Cheers, Daniel
-- Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.comhttp://www.kamailioworld.com Kamailio Advanced Training - Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.comhttp://www.asipto.com
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
+1 cookbook -giovanni
On Thu, Mar 14, 2019 at 11:39 PM Samuel F. samuel_is_kewl@hotmail.com wrote:
Agreed Alex, I think a cookbook with recommendations would be very useful to help get people started.
In the documentation, perhaps if there are a lot of stale/unused modules they could be moved to a different section as well or flagged with an icon so people know they are not a preferred choice for new/modern setups.
I suppose there are a number of different areas where a lot of people make decisions where one could just offer simple guidance such as:
Database: MySQL
Failover: Heartbeat
Kemi: app_python3
RTP: RTPEngine
I understand that not everyone would agree but would save new users a lot of work in comparing and trying to figure out what to choose for new projects. These recommendations would of course change with time as things evolve.
Regarding the rating system, not sure how to capture meaningful data that conveys the reality from the community. I think some of the veterans in the project who know what people use would provide more meaningful insight rather than a click drive vote or similar.
// Samuel
*From:* sr-users sr-users-bounces@lists.kamailio.org on behalf of Alex Balashov abalashov@evaristesys.com *Sent:* Thursday, March 14, 2019 14:19 *To:* Kamailio (SER) - Users Mailing List *Subject:* Re: [SR-Users] RFC: rating - ranking system for community
By way of further thought:
Perhaps a component-orientated view is not the correct one here. It almost sounds like what is being sought is a kind of "cookbook of Kamailio patterns"[1], if you like. This answers a lot of questions that also capture preferences about third-party FOSS componentry, such as:
"Should I do HA failover with VRRP or Heartbeat?"
"Is Kamailio + PostgreSQL a stable combination for a high-volume registrar?"
"Are there pitfalls to DMQ dialog replication?"
"What is the best way to build a load balancer with failover and gateway monitoring?"
etc.
-- Alex
[1] We use the term "cookbook" differently in this project, but this usage is closer to the commonplace conventional one.
On Thu, Mar 14, 2019 at 08:35:15AM -0400, Alex Balashov wrote:
Hi,
A few off-the-cuff thoughts, in no particular order:
- Kamailio does have hundreds of modules of all kinds, and some sort of
guide for which ones to use when, or some other schema which would serve to provide some conceptual organisation for the modules, is probably a desirable documentation objective.
- I am nevertheless wary of any system which purports to "rank" or
"rate" components.
One obvious reason is that popularity isn't a very good metric for whether something is appropriate for or applicable to a particular purpose. There is a reason the expression "degenerated into a popularity contest" exists in our industry. This is all the more true given (arguably) Kamailio's somewhat unique status as a "toolkit" or a "framework" for building certain kinds of systems and services; it means some of the most useful components in many scenarios might be either obscure, or so broadly general that a highly fact-dependent / situation-specific logic of its relationship to a given scenario is hard to tease out. Would you "recommend" the TM module? Is it widely used? :-)
This goes to another, more general problem with ranking components, and that is that the module ecosystem is a wildly eclectic bag of things of very different scope. Without a more rigid preconceived taxonomy to create the right mental categories, meaningful comparisons between modules are difficult to draw, as would be theoretically required for some kind of ranking or any system which purports to raise the profile of some components over others.
Kamailio modules fall into at least a few identifiable categories--this is just a half-hearted improvisational stab at it, and probably not very nuanced:
a. "Essential" / "core" - while these are technically modules, their feature set is so universal and critical to most non-trivial Kamailio implementations that they are substantially equivalent to "core" functionality. Modules like 'rr', 'tm' and 'pv' clearly fall into this category. One cannot really do anything worthy of remark with Kamailio without them, excluding some exotic cases.
b. Broad and holistic systems - complete categories of broad SIP server functionality implemented in more or less one module (usrloc + registrar, presence/pua, auth*, dispatcher, etc.);
c. Dependencies of other higher-level modules - the relationship of 'usrloc' to 'registrar' is suitably described by this; if you're using 'usrloc', you're almost certainly using 'registrar', and there are really no meaningful standalone uses of 'usrloc', nor does it expose any route script functions. At the same time, the list of things one may wish to interrogate via RPC/management interfaces are split between 'usrloc' and 'registrar' in ways that make sense to a programmer but which users might find arbitrary. In any case, do you give 'usrloc' a "thumbs up"? What does that even mean? :-)
Some modules are hybrids; they have some standalone functionality but are most commonly inputs into a higher-level usage, such as 'xhttp' and its relationship to 'jsonrpcs', or the various presence_* or pua_* subcomponents, some of the auth_* components, ims_*, etc.
d. Pure API dependencies of other modules - these expose internal APIs used by other modules and provide no standalone functionality others. One can debate whether 'usrloc' falls into this category, but certainly, 'dmq' is a good example of this, as are the various 'db_*' connectors, and maybe 'keepalive'.
e. Niche programmatic functionality - 'htable', 'cfgutils', 'jansson', 'async', etc. This category entails additional programmatic constructs relevant to the "software engineering" aspect of writing config/route script or how processing is done, but do not provide any external services or interfaces as such.
f. Broadly environmental - subtly alter the overall way that SIP messages are processed, or add support for new kinds of transports, etc. This would include 'tls', 'ws', 'outbound', and the 'topo{h,s}' modules.
g. Language / API / interpreter connectors - 'app_*' modules.
h. Highly specific functionality - most other modules fall into this. But some of the functionality is fairly high-level, e.g. 'rtpengine', while others are more low-level and closer to category E, such as 'mqueue'.
Anyway, the point here is that I don't think a vehicle to provide community guidance about which components to use, or which would purport to rank them somehow, can be meaningfully separated from the equally vital need to create some kind of taxonomy of modules or, more generally, adequate categories of thought within which such conversations should take place. Kamailio documentation lacks a clear and distinct "metaphysics" in this sense.
-- Alex
On Thu, Mar 14, 2019 at 09:55:41AM +0100, Daniel-Constantin Mierla wrote:
Hello,
starting to continue the discussions here on mailing lists about some
of
the approached topics during the last IRC meeting -- there will be couple of them.
The one now is about finding and deploying a ranking/rating system that could eventually help community members to make decisions easier in regard to what components to use in their voip systems.
The need was exemplified by user verticelo with the dificulty to decide what KEMI scripting language to use. While maintaining all the app_xyz are expected to be easy, at least I know that for those I created, the arguments were also from the perspective of the community. Like what others are using, so one can expect good assistance, hints and share of knowledge via community forums. This can be also extended to related tools, like what people use for shared IP high availability of
kamailio,
preferred database servers, ...
This email is to ask if those that didn't participate to IRC devel meeting find such system useful and, if there is a positive feedback,
is
anyone aware of some OSS that we can deploy on kamailio.org for such purpose? It should be something that allows posting a topic (title and short description) along with a list of answers/options (each can be again like a title and short description) and provide a way to rate the options (like, thumbs up, starts, ...), eventually allowing also comments for each option. I guess it sounds a bit like stackoverflow
...
Being users related, the email is sent only to sr-users, let's keep the discussion on this mailing list.
Cheers, Daniel
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com Kamailio Advanced Training - Mar 25-27, 2019, in Washington, DC, USA
-- www.asipto.com
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Am Donnerstag, 14. März 2019, 14:19:22 CET schrieb Alex Balashov:
Perhaps a component-orientated view is not the correct one here. It almost sounds like what is being sought is a kind of "cookbook of Kamailio patterns"[1], if you like. This answers a lot of questions that also capture preferences about third-party FOSS componentry, such as:
"Should I do HA failover with VRRP or Heartbeat?"
"Is Kamailio + PostgreSQL a stable combination for a high-volume registrar?"
"Are there pitfalls to DMQ dialog replication?"
Hi Alex,
to continue on this idea - the "big complex enterprise software vendors" (e.g. SAP) provides so called "value maps". They provide a way how to plan, deploy and operation a certain technology stack. It starts with a general knowledge base and then continue with deployment best-practices and guidelines on certain tasks or events.
Exactly as you described:
"What is the best way to build a load balancer with failover and gateway monitoring?"
I also think this approach would be a better fit as just a rating system. That said, we probably could flag the existing modules a bit better (there is some status on the main overview page, but it is not visible e.g. in the README). https://kamailio.org/docs/modules/5.2.x/
They have been some more comments in favor of the cookbook approach. Is there somebody from the community interested in continuing on this, maybe creating a first draft document or something in this regards?
[1] We use the term "cookbook" differently in this project, but this usage is closer to the commonplace conventional one.
On Thu, Mar 14, 2019 at 08:35:15AM -0400, Alex Balashov wrote:
Hi,
A few off-the-cuff thoughts, in no particular order:
- Kamailio does have hundreds of modules of all kinds, and some sort of
guide for which ones to use when, or some other schema which would serve to provide some conceptual organisation for the modules, is probably a desirable documentation objective.
- I am nevertheless wary of any system which purports to "rank" or
"rate" components.
One obvious reason is that popularity isn't a very good metric for whether something is appropriate for or applicable to a particular purpose. There is a reason the expression "degenerated into a popularity contest" exists in our industry. This is all the more true given (arguably) Kamailio's somewhat unique status as a "toolkit" or a "framework" for building certain kinds of systems and services; it means some of the most useful components in many scenarios might be either obscure, or so broadly general that a highly fact-dependent / situation-specific logic of its relationship to a given scenario is hard to tease out. Would you "recommend" the TM module? Is it widely used?
:-)
This goes to another, more general problem with ranking components, and that is that the module ecosystem is a wildly eclectic bag of things of very different scope. Without a more rigid preconceived taxonomy to create the right mental categories, meaningful comparisons between modules are difficult to draw, as would be theoretically required for some kind of ranking or any system which purports to raise the profile of some components over others.
Kamailio modules fall into at least a few identifiable categories--this is just a half-hearted improvisational stab at it, and probably not very nuanced:
a. "Essential" / "core" - while these are technically modules, their feature set is so universal and critical to most non-trivial Kamailio implementations that they are substantially equivalent to "core" functionality. Modules like 'rr', 'tm' and 'pv' clearly fall into this category. One cannot really do anything worthy of remark with Kamailio without them, excluding some exotic cases.
b. Broad and holistic systems - complete categories of broad SIP server functionality implemented in more or less one module (usrloc + registrar, presence/pua, auth*, dispatcher, etc.);
c. Dependencies of other higher-level modules - the relationship of 'usrloc' to 'registrar' is suitably described by this; if you're using 'usrloc', you're almost certainly using 'registrar', and there are really no meaningful standalone uses of 'usrloc', nor does it expose any route script functions. At the same time, the list of things one may wish to interrogate via RPC/management interfaces are split between 'usrloc' and 'registrar' in ways that make sense to a programmer but which users might find arbitrary. In any case, do you give 'usrloc' a "thumbs up"? What does that even mean? :-)
Some modules are hybrids; they have some standalone functionality but are most commonly inputs into a higher-level usage, such as 'xhttp' and its relationship to 'jsonrpcs', or the various presence_* or pua_* subcomponents, some of the auth_* components, ims_*, etc.
d. Pure API dependencies of other modules - these expose internal APIs used by other modules and provide no standalone functionality others. One can debate whether 'usrloc' falls into this category, but certainly, 'dmq' is a good example of this, as are the various 'db_*' connectors, and maybe 'keepalive'.
e. Niche programmatic functionality - 'htable', 'cfgutils', 'jansson', 'async', etc. This category entails additional programmatic constructs relevant to the "software engineering" aspect of writing config/route script or how processing is done, but do not provide any external services or interfaces as such.
f. Broadly environmental - subtly alter the overall way that SIP messages are processed, or add support for new kinds of transports, etc. This would include 'tls', 'ws', 'outbound', and the 'topo{h,s}' modules.
g. Language / API / interpreter connectors - 'app_*' modules.
h. Highly specific functionality - most other modules fall into this. But some of the functionality is fairly high-level, e.g. 'rtpengine', while others are more low-level and closer to category E, such as 'mqueue'.
Anyway, the point here is that I don't think a vehicle to provide community guidance about which components to use, or which would purport to rank them somehow, can be meaningfully separated from the equally vital need to create some kind of taxonomy of modules or, more generally, adequate categories of thought within which such conversations should take place. Kamailio documentation lacks a clear and distinct "metaphysics" in this sense.
-- Alex
On Thu, Mar 14, 2019 at 09:55:41AM +0100, Daniel-Constantin Mierla wrote:
Hello,
starting to continue the discussions here on mailing lists about some of the approached topics during the last IRC meeting -- there will be couple of them.
The one now is about finding and deploying a ranking/rating system that could eventually help community members to make decisions easier in regard to what components to use in their voip systems.
The need was exemplified by user verticelo with the dificulty to decide what KEMI scripting language to use. While maintaining all the app_xyz are expected to be easy, at least I know that for those I created, the arguments were also from the perspective of the community. Like what others are using, so one can expect good assistance, hints and share of knowledge via community forums. This can be also extended to related tools, like what people use for shared IP high availability of kamailio, preferred database servers, ...
This email is to ask if those that didn't participate to IRC devel meeting find such system useful and, if there is a positive feedback, is anyone aware of some OSS that we can deploy on kamailio.org for such purpose? It should be something that allows posting a topic (title and short description) along with a list of answers/options (each can be again like a title and short description) and provide a way to rate the options (like, thumbs up, starts, ...), eventually allowing also comments for each option. I guess it sounds a bit like stackoverflow ...
Being users related, the email is sent only to sr-users, let's keep the discussion on this mailing list.
Cheers,
Henning
-
Alex Balashov -
Daniel-Constantin Mierla -
Giovanni Maruzzelli -
Henning Westerholt -
Samuel F.