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: -- 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(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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?"

[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: > > 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.