[SR-Users] RFC: rating - ranking system for community

[Alex Balashov]

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 at 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/