[SR-Users] Kamailio developers meeting - follow up remarks

[Daniel-Constantin Mierla]

Hello,

one addition to section 8):

  * it was discussed if internal libraries still have a good purpose,
given low activity there and some of the libs there are used in a few
modules, which case also use intermodule API, while some are becoming
more like general purpose scope (json lib, with use in rpc control
interface, or uuid). There is also some complexity added to packaging
dependencies, as many packages we do with modules depend on same
internal lib. As a result, code from internal libs may be relocated over
time.

Cheers,
Daniel

On 22.11.19 09:59, Daniel-Constantin Mierla wrote:
> Hello,
>
> last week we had the 2nd annual Kamailio Developers Meeting hosted by
> Sipgate in Dusseldorf, Germany:
>
>   * https://www.kamailio.org/w/developers-meeting/
>
> 16 people were at the event in various roles.
>
> Giacomo Vacca published on his blog a good summary of what happened there:
>
>   *
> https://www.giacomovacca.com/2019/11/my-notes-on-kamailio-developer-meeting.html
>
> This year we had a lot of discussions, as well as work done on multiple
> planes, not only Kamailio code. So I am trying to list here some of the
> conclusions for future development, the technical aspects of the
> meeting, so everyone is aware and can provide feedback.
>
> 1) Effective work was done on:
>
>   * kamailio code
>   * kamailio rpm packaging
>   * kamailio tools (kamctl)
>   * kamailio release process
>   * kamailio project keys (to be used to sign the packages)
>
> 2) Documentation
>
> 2.a) Wiki
>
>   * it was somehow a rough consensus to move the wiki content to github,
> along with changing the format from dokuwiki markdown to the
> standard/github markdown. This should enable people to make pull
> requests so developers or community members can review and aprove new
> content. It also makes it easier to contribute using existing github
> account, now the kamailio.org/wiki is requiring to make a dedicated
> account, which many prefer not to do it.
>
>   * the presentation can be done either by using mkdocs to generate html
> files hosted on kamailio.org or using the github provided wiki portal.
>
>  2.b) Docs for variables and transformations
>
>   * there was a proposal to move them in the documentation the modules
> that export them, there are pros and cons, needs more discussions. Now
> they are in the wiki, so this probably has to resume after deciding on 2.a).
>
> 3) Kamailio Modules
>
> 3.a) replication (dmq) - several participants discussed about
> negotiations between nodes to take active role on some cases (e.g.,
> active dialogs)
>
> 3.b) api integration - quite some interest in JSON-based API routing,
> concluding in extending rtjson to cover more use cases
>
> 3.c) security - have options to restrict the use of TLS1.3 or newer
>
> 4) Kamailio Releases
>
>   * v5.3.2 was released during the event, allowing to document the process
>   * work to automatize the process is planned, then eventually assing
> teams for takeing cares of releases from specific branches
>
> 5) Kamailio Testing
>
>   * existing docker-based testing framework should be extended and
> integrated in CD/CI pipeline
>
> 6) Kamailio packages
>
> 6.a) rpms
>
>   * rpm.kamailio.org has been prepared and is expected to take over the
> opensuse build service for building rpms and hosting them. Expected to
> provide support for hosting many kamailio versions in the same release
> series so one can do downgrade to older releases. Also, there is work in
> progress to provide nightly builds.
>
> 6.b) debs
>
>   * work is planned to offer many kamailio versions in the same release
> series
>
> 7) Kamailio tools
>
>   * kamctl/kamdbctl should be obsoleted in favor of kamcli, which offers
> a better framework for input validation and output formatting, as well
> as better portability, no longer depending on shell interpreter
>
> 8) Various discussions
>
>   * kemi exports from C point of view and how to combine the
> documentation for modules and their kemi exports
>   * how to make kamaiio friendlier in virtualized environments (ended up
> in the need of making the use of advertised address a bit more dynamic)
>   * project organizatoric topics - to be approached separately
>   * next events - Fosdem - someone should submit a proposal to present
> about Kamailio
>
> 9) Long term goals
>
> We speak here more or less about Kamailio 6.0 ...
>
>   * change the behaviour of the native config interpreter to be
> consistent with the other programming languages in terms of handling the
> response code (change what is now: the evaluation of negative value to
> false and positive value to true and the hidden return 0 to exit)
>
>   * make the pool of processes more generic, so they can handle traffic
> from more sockets (being sip traffic or something else) -- this should
> make better use of resources, as some sockets might be less busy that others
>
> I hope I covered the important topics, if I remember something else, I
> will reply on this thread. Or maybe other participants can contribute
> missing topics.
>
> Should anyone have comments or suggestions on the above topics, or new
> ones, let's discuss on sr-users because it impacts the long term use of
> Kamailio (sr-dev is cc-ed now for notification purposes).
>
> Overall, there were 2 very intensive days, however in a friendly and
> relaxed environment offered by Sipgate. Extremely useful discussions,
> not only about Kamailio, but about RTC ecosystem. At the evening social
> network event event, a couple of external people joined, some of them
> presenting very interesting use cases of Kamailio.
>
> Many thanks to all participants that allocated time and resources to
> come to Dusseldorf, as well as to the companies that covered expenses
> for participants.
>
> Cheers,
> Daniel
>
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com