+1 cookbook -giovanni
On Thu, Mar 14, 2019 at 11:39 PM Samuel F. <[email protected]> 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 <[email protected]> on behalf of Alex > Balashov <[email protected]> > *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 > > > [email protected] > > > 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 > > [email protected] > > 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 > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- Sincerely, Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
