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

Fri Mar 15 14:06:50 CET 2019

+1 cookbook
-giovanni

On Thu, Mar 14, 2019 at 11:39 PM Samuel F. <samuel_is_kewl at 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 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
> > > 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/
> >
> > _______________________________________________
> > 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
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>

-- 
Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190315/cd283049/attachment.html>