<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Agreed Alex, I think a cookbook with recommendations would be very useful to help get people started.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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:</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="font-family: Calibri, Helvetica, sans-serif; background-color: rgb(255, 255, 255); display: inline !important">Database: MySQL</span><br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="font-family: Calibri, Helvetica, sans-serif; background-color: rgb(255, 255, 255); display: inline !important"><br>
</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Failover: Heartbeat</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Kemi: app_python3</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
RTP: RTPEngine</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
// Samuel</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> sr-users <sr-users-bounces@lists.kamailio.org> on behalf of Alex Balashov <abalashov@evaristesys.com><br>
<b>Sent:</b> Thursday, March 14, 2019 14:19<br>
<b>To:</b> Kamailio (SER) - Users Mailing List<br>
<b>Subject:</b> Re: [SR-Users] RFC: rating - ranking system for community</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">By way of further thought:<br>
<br>
Perhaps a component-orientated view is not the correct one here. It<br>
almost sounds like what is being sought is a kind of "cookbook of<br>
Kamailio patterns"[1], if you like. This answers a lot of questions<br>
that also capture preferences about third-party FOSS componentry, such<br>
as:<br>
<br>
"Should I do HA failover with VRRP or Heartbeat?"<br>
<br>
"Is Kamailio + PostgreSQL a stable combination for a high-volume<br>
registrar?"<br>
<br>
"Are there pitfalls to DMQ dialog replication?"<br>
<br>
"What is the best way to build a load balancer with failover and gateway<br>
monitoring?"<br>
<br>
etc.<br>
<br>
-- Alex<br>
<br>
[1] We use the term "cookbook" differently in this project, but this<br>
usage is closer to the commonplace conventional one.<br>
<br>
On Thu, Mar 14, 2019 at 08:35:15AM -0400, Alex Balashov wrote:<br>
<br>
> Hi,<br>
> <br>
> A few off-the-cuff thoughts, in no particular order:<br>
> <br>
> 1. Kamailio does have hundreds of modules of all kinds, and some sort of<br>
> guide for which ones to use when, or some other schema which would serve<br>
> to provide some conceptual organisation for the modules, is probably a<br>
> desirable documentation objective. <br>
> <br>
> 2. I am nevertheless wary of any system which purports to "rank" or<br>
> "rate" components. <br>
> <br>
> One obvious reason is that popularity isn't a very good metric for<br>
> whether something is appropriate for or applicable to a particular<br>
> purpose. There is a reason the expression "degenerated into a popularity<br>
> contest" exists in our industry. This is all the more true given<br>
> (arguably) Kamailio's somewhat unique status as a "toolkit" or a<br>
> "framework" for building certain kinds of systems and services; it means<br>
> some of the most useful components in many scenarios might be either<br>
> obscure, or so broadly general that a highly fact-dependent /<br>
> situation-specific logic of its relationship to a given scenario is hard<br>
> to tease out. Would you "recommend" the TM module? Is it widely used?<br>
> :-)<br>
> <br>
> This goes to another, more general problem with ranking components, and<br>
> that is that the module ecosystem is a wildly eclectic bag of things of<br>
> very different scope. Without a more rigid preconceived taxonomy to<br>
> create the right mental categories, meaningful comparisons between<br>
> modules are difficult to draw, as would be theoretically required for<br>
> some kind of ranking or any system which purports to raise the profile<br>
> of some components over others. <br>
> <br>
> Kamailio modules fall into at least a few identifiable categories--this<br>
> is just a half-hearted improvisational stab at it, and probably not very<br>
> nuanced:<br>
> <br>
> a. "Essential" / "core" - while these are technically modules, their<br>
> feature set is so universal and critical to most non-trivial Kamailio<br>
> implementations that they are substantially equivalent to "core"<br>
> functionality. Modules like 'rr', 'tm' and 'pv' clearly fall into this<br>
> category. One cannot really do anything worthy of remark with Kamailio<br>
> without them, excluding some exotic cases.<br>
> <br>
> b. Broad and holistic systems - complete categories of broad SIP server<br>
> functionality implemented in more or less one module (usrloc +<br>
> registrar, presence/pua, auth*, dispatcher, etc.);<br>
> <br>
> c. Dependencies of other higher-level modules - the relationship of<br>
> 'usrloc' to 'registrar' is suitably described by this; if you're using<br>
> 'usrloc', you're almost certainly using 'registrar', and there are<br>
> really no meaningful standalone uses of 'usrloc', nor does it expose any<br>
> route script functions. At the same time, the list of things one may<br>
> wish to interrogate via RPC/management interfaces are split between<br>
> 'usrloc' and 'registrar' in ways that make sense to a programmer but<br>
> which users might find arbitrary. In any case, do you give 'usrloc' a<br>
> "thumbs up"? What does that even mean? :-)<br>
> <br>
> Some modules are hybrids; they have some standalone functionality but<br>
> are most commonly inputs into a higher-level usage, such as 'xhttp' and<br>
> its relationship to 'jsonrpcs', or the various presence_* or pua_*<br>
> subcomponents, some of the auth_* components, ims_*, etc.<br>
> <br>
> d. Pure API dependencies of other modules - these expose internal APIs<br>
> used by other modules and provide no standalone functionality others.<br>
> One can debate whether 'usrloc' falls into this category, but certainly,<br>
> 'dmq' is a good example of this, as are the various 'db_*' connectors,<br>
> and maybe 'keepalive'.<br>
> <br>
> e. Niche programmatic functionality - 'htable', 'cfgutils', 'jansson',<br>
> 'async', etc. This category entails additional programmatic constructs<br>
> relevant to the "software engineering" aspect of writing config/route<br>
> script or how processing is done, but do not provide any external<br>
> services or interfaces as such.<br>
> <br>
> f. Broadly environmental - subtly alter the overall way that SIP<br>
> messages are processed, or add support for new kinds of transports, etc.<br>
> This would include 'tls', 'ws', 'outbound', and the 'topo{h,s}' modules.<br>
> <br>
> g. Language / API / interpreter connectors - 'app_*' modules.<br>
> <br>
> h. Highly specific functionality - most other modules fall into this.<br>
> But some of the functionality is fairly high-level, e.g. 'rtpengine',<br>
> while others are more low-level and closer to category E, such as<br>
> 'mqueue'.<br>
> <br>
> <br>
> Anyway, the point here is that I don't think a vehicle to provide<br>
> community guidance about which components to use, or which would purport<br>
> to rank them somehow, can be meaningfully separated from the equally<br>
> vital need to create some kind of taxonomy of modules or, more<br>
> generally, adequate categories of thought within which such<br>
> conversations should take place. Kamailio documentation lacks a clear<br>
> and distinct "metaphysics" in this sense.<br>
> <br>
> -- Alex<br>
> <br>
> On Thu, Mar 14, 2019 at 09:55:41AM +0100, Daniel-Constantin Mierla wrote:<br>
> <br>
> > Hello,<br>
> > <br>
> > starting to continue the discussions here on mailing lists about some of<br>
> > the approached topics during the last IRC meeting -- there will be<br>
> > couple of them.<br>
> > <br>
> > The one now is about finding and deploying a ranking/rating system that<br>
> > could eventually help community members to make decisions easier in<br>
> > regard to what components to use in their voip systems.<br>
> > <br>
> > The need was exemplified by user verticelo with the dificulty to decide<br>
> > what KEMI scripting language to use. While maintaining all the app_xyz<br>
> > are expected to be easy, at least I know that for those I created, the<br>
> > arguments were also from the perspective of the community. Like what<br>
> > others are using, so one can expect good assistance, hints and share of<br>
> > knowledge via community forums. This can be also extended to related<br>
> > tools, like what people use for shared IP high availability of kamailio,<br>
> > preferred database servers, ...<br>
> > <br>
> > This email is to ask if those that didn't participate to IRC devel<br>
> > meeting find such system useful and, if there is a positive feedback, is<br>
> > anyone aware of some OSS that we can deploy on kamailio.org for such<br>
> > purpose? It should be something that allows posting a topic (title and<br>
> > short description) along with a list of answers/options (each can be<br>
> > again like a title and short description) and provide a way to rate the<br>
> > options (like, thumbs up, starts, ...), eventually allowing also<br>
> > comments for each option. I guess it sounds a bit like stackoverflow ...<br>
> > <br>
> > Being users related, the email is sent only to sr-users, let's keep the<br>
> > discussion on this mailing list.<br>
> > <br>
> > Cheers,<br>
> > Daniel<br>
> > <br>
> > -- <br>
> > Daniel-Constantin Mierla -- <a href="http://www.asipto.com">www.asipto.com</a><br>
> > <a href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda">
www.linkedin.com/in/miconda</a><br>
> > Kamailio World Conference - May 6-8, 2019 -- <a href="http://www.kamailioworld.com">
www.kamailioworld.com</a><br>
> > Kamailio Advanced Training - Mar 25-27, 2019, in Washington, DC, USA -- <a href="http://www.asipto.com">
www.asipto.com</a><br>
> > <br>
> > <br>
> > _______________________________________________<br>
> > Kamailio (SER) - Users Mailing List<br>
> > sr-users@lists.kamailio.org<br>
> > <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
> <br>
> -- <br>
> Alex Balashov | Principal | Evariste Systems LLC<br>
> <br>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) <br>
> Web: <a href="http://www.evaristesys.com/">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/">
http://www.csrpswitch.com/</a><br>
> <br>
> _______________________________________________<br>
> Kamailio (SER) - Users Mailing List<br>
> sr-users@lists.kamailio.org<br>
> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br>
-- <br>
Alex Balashov | Principal | Evariste Systems LLC<br>
<br>
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) <br>
Web: <a href="http://www.evaristesys.com/">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/">
http://www.csrpswitch.com/</a><br>
<br>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
sr-users@lists.kamailio.org<br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</div>
</span></font></div>
</body>
</html>