<div dir="ltr"><div><br></div><div>+1 cookbook</div><div>-giovanni</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 14, 2019 at 11:39 PM Samuel F. <<a href="mailto:samuel_is_kewl@hotmail.com">samuel_is_kewl@hotmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div 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">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"><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="gmail-m_5539570950172158817appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_5539570950172158817divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> sr-users <<a href="mailto:sr-users-bounces@lists.kamailio.org" target="_blank">sr-users-bounces@lists.kamailio.org</a>> on behalf of Alex Balashov <<a href="mailto:abalashov@evaristesys.com" target="_blank">abalashov@evaristesys.com</a>><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="gmail-m_5539570950172158817BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="gmail-m_5539570950172158817PlainText">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 <a href="http://kamailio.org" target="_blank">kamailio.org</a> 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" target="_blank">www.asipto.com</a><br>
> > <a href="http://www.twitter.com/miconda" target="_blank">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" target="_blank">
www.linkedin.com/in/miconda</a><br>
> > Kamailio World Conference - May 6-8, 2019 -- <a href="http://www.kamailioworld.com" target="_blank">
www.kamailioworld.com</a><br>
> > Kamailio Advanced Training - Mar 25-27, 2019, in Washington, DC, USA -- <a href="http://www.asipto.com" target="_blank">
www.asipto.com</a><br>
> > <br>
> > <br>
> > _______________________________________________<br>
> > Kamailio (SER) - Users Mailing List<br>
> > <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
> > <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">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/" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" target="_blank">
http://www.csrpswitch.com/</a><br>
> <br>
> _______________________________________________<br>
> Kamailio (SER) - Users Mailing List<br>
> <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">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/" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" target="_blank">
http://www.csrpswitch.com/</a><br>
<br>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</div>
</span></font></div>
</div>

_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Sincerely,<br><br>Giovanni Maruzzelli<br>OpenTelecom.IT<br>cell: +39 347 266 56 18<br><br></div>