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

Samuel F. samuel_is_kewl at hotmail.com
Thu Mar 14 23:36:43 CET 2019


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 at lists.kamailio.org> on behalf of Alex Balashov <abalashov at 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:
>
> 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<http://www.asipto.com>
> > www.twitter.com/miconda<http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>
> > Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com<http://www.kamailioworld.com>
> > Kamailio Advanced Training - Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com<http://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/
>
> _______________________________________________
> 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/

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190314/096810fc/attachment.html>


More information about the sr-users mailing list