Online Devel Meeting - 2022-12-08

Note: the online meeting is planned to be hosted on a Matrix room where we will try to grant guest access and people can join via web browser. See more details below.


  • Proposed: 15:00 UTC, Thursday, Dec 08, 2022
    • can attend: dcm, oej, vseva, ...
    • cannot attend:

Time of the meeting across the world:

  • 16:00 - Berlin, Germany
  • 15:00 - London, UK
  • 10:00 - New York, USA
  • 07:00 - Seattle, USA




Participation is open to anyone, just join the chat room if you want to participate.

People adding notes in the agenda using abbreviations:

  • dcm - Daniel-Constantin Mierla
  • vseva - Victor Seva


Kamailio Development Status:

  • summary and follow up on Dusseldorf devel meeting (dcm)
  • open issues (dcm)
  • minor releases for 5.5 and 5.6 branches (dcm)
  • tracker issues review:
  • packaging and distributions
  • continuous integration
    • use of github actions


  • servers maintenance
  • community interaction and communication channels
  • existing mailing lists review

Kamailio 5.7 (next major release):

  • aim for 5.7 or 6.0
  • roadmap
  • features
    • anything relevant that is missing?
    • priorities


  • updates for wiki with markdown and mkdocs (github markdown)

Collaborative Projects:

  • unit testing, documentation, etc.
  • community announcements


Thu, Dec 8 2022

fyi: on this channel, today at 15:00UTC (16:00Berlin) starts the online kamailio devel meeting

starting devel meeting in about 10min

Ready with a cup of tea

Víctor Seva

Henning Westerholt

Hello everyone!
let's allow 2-3 more mins
if anyone has pre-meeting questions, we can discuss shorty
ok ... hopefully it was enough time for the late comers to join
we can start the online kamailio devel meeting
sort of draft for agenda:
everyone feel free to propose topics, probably the best is at the end ...
first topic would the summary and follow up after Dusseldorf devel meeting
I worked on a few things, the largest being switch from int to long for cfg variables
which had impact pretty much everywhere
the work continued afterwards, I think right now the foundation for it is in place
many variables support it (avps, xavps, var, shv, ...)
the main reason was that most of the systems now have 64bit CPUs, time and many values are long, which no longer fit well on 32bit integer
on 32bit system, should be no impact, long and int are both using 32bit

on 64bit CPU the memory is aligned to at least 64bit, so the impact should not be significant in terms of real usage of memory
now, various variables in different module might still use int internally, I havent checked everything, but that should happen over the time, when discovered that is needed
helping with testing and reporting issues are appreciated, of course!
another work was about propagating the return code value, because of the evaluation mode in kamailio (<0 is false, >0 is true), the return code from functions was "lost" in the config interpreter processing
this has impact on config expressions
is disabled by default
but allows to get to a style that is more "standard" in behaviour
I am planning to add a mode when return 0 is no longer automatically exit
so one would have to do it in config: if(func()==0) exit;

Henning Westerholt
if we want to enable by default, we should review the modules, a few functions are using return 0 as exit
nothing against it, just need to be considered

it will stay the same, return 0, just the config writer has to deal with
then, one small bit was adding a helper function that would allow evaluating the function parameter in a specified buffer, not in the core pv buffers
useful when it is expected to get a very large value ... Federico reported such a case
jansson got a special function to cope with the case, then I thought it would be useful to have the helper function in case it will be needed for other cases
now maybe Henning Westerholt wants to write about his work
not sure if Federico Cabiddu is online now, if yes, he can write as well

Henning Westerholt
Thanks Daniel. I looked into the dialog module, they are some race-conditions that are still beeing reported. I also looked into the new wolfssl module and some IMS extensions/ pull-requests (like the new IMS db_mode that was merged some days ago).
Regarding dialog module, I removed some debugging functions which probably causes race-conditions, lets wait for more feedback on that issue on the tracker.
Not sure if Alexander is online as well, they were working on performance tracing topics and siptrace module extensions

Federico Cabiddu
here I am sorry, busy afternoon :)
yes, we have deployed the new jansson function and everything works and no issue to report

Víctor Seva
I would like to mention that we are having issues with transactions and shared memory. While a transaction is being processed, CANCEL comes and boom

Federico Cabiddu: no worries, I can make the summary further if you are busy

Víctor Seva
I have to say that we are doing too much inside the processing

Víctor Seva: there were some commits related to this case, didn't they fix it?

Federico Cabiddu
on my side of development I still have to finalize the implemeteton of OpenMetrics for xhttp_prom modules and for internal statistics

ok, so Henning listed what Alexandr was working on, let's see if he comes back with some commits

Víctor Seva
we can talk about that another day, I just wanted to mention that the problem, at least for us is still there

otherwise, to end about Dusseldorf, we worked "hard" on some very good breakfasts, lunches and evening event, all courtesy of, many thanks again to them and Markus for hosting us!
next year we hope to get a larger group of people, but this one was not bad at all, given the conditions world wide!

Henning Westerholt
It was a great re-start indeed

if no questions about Dusseldorf, then we can move to: open issues
Víctor Seva reported one, it would be good to get new traces, after the previous commits
anything else to report?
from the tracker (and list), the kamcmd with no autocompletion anymore, apparently due to newer ncurses library
openssl 3.0 support ...

Henning Westerholt
kamcmd is broken since a long time, like years
but as you wrote, there are alternatives for sure

Stefan Mititelu -> anyone encountered this too?

not using python myself -- do you need 2.7? have you tried with 3.x?

Stefan Mititelu
not tried, will do

Henning Westerholt
on newer distributions app_python(2) is not available anymore anyway

speaking of that, I actually just added app_python3s module ;)

Henning Westerholt
yes :) can you explain in a nutshell what its about?

but that mainly because I wanted to make a variant more similar to the other kemi modules
app_python3 was based on old module, with a design that create a message object

Henning Westerholt
ok, got it

which has to be initialized in the mod_init python callback and a kamailio class defined for it
the python3s is simply statically exports KSR object and expect global functions with name ksr_request_route()/ksr_reply_route() ... no object, no other parameters
from performance point of view, does not seem to be significant gain, maybe in range of microseconds, but the script becomes more similar to the other kemi interpreters

Henning Westerholt
More similar is also a good thing. Regarding app_python, it probably make sense to deprecate it for next release

native config, lua, python3 and ruby give similar performace results, tested with registrations and db authentication
haven't tested python2
app_jsdt seems a bit slower, like 40-50 microseconds slower in average
but even so, it still processes like 3500-4000 registrations per second per udp worker process

Henning Westerholt
regarding issues, already mentioned the dialog topic, waiting for feedback here
there is some crash about acc_json, but this was for a EOL release

so I would not be worried about capacity of processing with any of the kemi modules
to be clear, the difference was in microseconds, not milliseconds
and to end about kemi, I reorganized a bit the code, so a lot of duplicated code that was in each kemi module is now in core ... beter modularity and easier to extend in the future

Stefan Mititelu
Henning Westerholt: related to the EOL crash, can't be reproduced and happens seldom(few months interval); maybe upgrading and including the "print_lists" fix will fix the possible race conditions.

we can continue to issues reported to the tracker, mainly from feature requests point of view
probably the very old ones should be closed, unless some devel wants to work on specific ones
in which case, should leave a comment there

Henning Westerholt
regarding feature requests, the stir-shaken cert caching stuff looks ok now, this one can then be closed after merging

regarding next minor releases: I haven't checked how many commits got in the branches, probably there will be new releases in 5.5 and 5.6 either before the winter holidays, or in January 2023
I will have to review the branches
unless someone considers it is pretty urgent to hurry up because of some fixes
we do have nightly builds, though, if one needs to deploy ahead
well, for debian/ubuntu, not sure about rpms

Henning Westerholt
CentOS RPMs will get over time less important, people will move away to Debian/Ubuntu or some other RPM based distros

I think rpms are for a bunch of distros, including suse and fedora ...

Henning Westerholt
the rpm service is AFAIK only for CentOS
opensuse, yes


Henning Westerholt
ah, you are right, my fault

coming to CI and github actions
there is PR which seemed a bit strange, being related to CodeQL and LGTM
because github offered somehow integration with LGTM and it is active for kamailio
not sure if they are going to change it and needs to be moved to GH actions

Henning Westerholt
yes, I looked into it

or codeql is something different

Henning Westerholt
Victor and I already reviewed, seems to be ok. They basically got bought from github
so the lgtm will be switched off
and the new service replaces it
its moved from gh app to gh actions


Henning Westerholt
we will get some new reports, need probably some time to fine-tune it, as they extended it a bit

anything else that we should add to GH actions?
if anyone has suggestions from their other projects ...

Víctor Seva
It would be nice to have a clang format check

Henning Westerholt
you mean, like for coding style? or for correctness

Víctor Seva
Coding style

Henning Westerholt
we still have different coding styles in the modules, which can be a bit confusing. maybe this needs to be harmonized first

there is a clang-format file in root directory
that is used when calling clang format
I did it for a couple of modules
the only thing I was missing (or disliking) was the structure formatting
it is not done uniform, being a matter of line length
I mean about variables being assigned with a structure, like module exports
but can be dealt with by using clang format on/off

Víctor Seva
If we want to unify coding style, we have to enforce it.
I can volunteer to generate the commits formating with clang tool

I am not against using clang format, pretty ok for me

Víctor Seva
One commit per module

I think some were concerned about tracking changes (Henning?!?) ...
like when using git blame ...

Henning Westerholt
yes, this is the only thing. but if we want to have a uniform style, there is no other way
one can of course also got back one release etc..
When changing the modules, we probably should exclude the "special" structures like Daniel mentioned

so when it is done, has to be done for all code and have like a new tracking point 0

Henning Westerholt

anything else for GH actions?

Víctor Seva
I'm going to be blamed, no problema

ok, then infrastructure (maintenance), communication channels/mailing lists
for infrastructure, soon there should be a server upgrade for
to move to latest stable before old stable goes unmaintained ...
maybe even this year, if the time allows it, need to sync with Oriol just in case we have to revert to a backup snapshot
probably a bunch of 5-10 mins downtime intervals ... for reboots and tunnings
for communication channels/mailing lists, all fine for me, but if someone has new suggestions, I am open to discuss

Henning Westerholt
sounds like a good plan, update would be nice

Fred Posner
I think mail is more than enough notice

Henning Westerholt
maybe we can get a bit more CPU power, the spam filter job is really inefficient implemented right now
maybe they can move it to a newer architecture/physical host, should already help a lot

it is a 4 CPU system

Henning Westerholt
i noticed that sometimes it takes like 10-15min to process a list to the mailing list due to the spam filter, but might be also some issues from time to time

the load does not seem high, maybe the spam daemon needs some care

Henning Westerholt
look after you send some messages to the list, then it goes up
it filters every messages many times basically
but it works, not critical sure

ok -- we have spamassassin, maybe there are better options these days
I will check and if more cpu helps, we will ask for
anything else on ifrastructure?

Henning Westerholt
github wiki seems to be fine, not that much PRs yet,though
nothing else from my side

miconda indeed, at least we don't have to deal with user accounts and spam anymore

Henning Westerholt yes, thats great

still many pages need updates for proper markdown formatting, some old dokuwiki styles are still there
but they are readable ...
so then we covered "updates for wiki with markdown and mkdocs", if nobody wants to add on this topic
then: next major release
5.7 or 6.0?
anything relevant missing?
and roadmap/timelines ...
hard to decide ...
about 5.7 or 6.0, I guess
changes related to long and return code can lead to a 6.0 ...

Henning Westerholt
I'd go for 6.0 if we make some breaking changes (like the earlier discussed return code topic) that needs some user cfg refactoring. Otherwise currently its more a 5.7, i think
if we leave it disabled, old status kept

what about code format, should that matter for a 6.0?

Henning Westerholt
coding style of modules? its more an internal topic, probably not that relevant for users

yep, but as reference, about contribution styles ...

Henning Westerholt
ok, sure if we get some more strict rules about it, got it

backports might not be easy afterwards
with the current mode of cherry-picking

Henning Westerholt
this is true
nothing against 6.0, but previously I thought its not yet decided if you want to go for switching the return code as default

maybe also the today's PR discussion about log levels has to be sorted out for next release
then 5.7 vs 6.0 can be decided later, as things move on and see where they get
probably as a timeline, freezing should somewhere in the first part of spring 2023
not sure if earlier makes sense
aiming to release april-may 2023 ...

Henning Westerholt
Sounds good
regarding further development, there are probably some more extensions for the IMS modules coming in, similar to the db_mode extensions merged some days ago

@oej proposed SPDX identifiers for code (SBOM - Software Bill of Materials) ...

Henning Westerholt
might be also a larger change with some impact on merging/code structure

not sure if oej is still around at this time ...

Henning Westerholt
he seems to be really interested in it, but of course difficult to guess about his schedule/plans regarding additions

ok, we wait for him to write on mailing list ...
anything else to discuss?

Henning Westerholt
there were some discussions/PR about async rtpengine - but it seems to be feasible by other (non-code) means, which is of course better
the other PRs are more extensions or some smaller changes

miconda as for events next year: FOSDEM 2023 is going to be in person in Brussels, February 4-5
RTC devroom is half day on Feb 5 (Sunday)

Henning Westerholt yes, I will be there if all works out with traveling
and not another virus comes around :)
have you decided already about your plans?

and if world runs smooth, Kamailio World 2023 will be also in-person, in Berlin, June 5-7
for Fosdem, not decided yet, I will try to be there as every year, but booking the trip will be days before, because it is not easy to cancel and there is still high risk of not being able to travel
it is winter season and many viruses seem to have fun around :-)
that's the reason we pushed a bit Kamailio World more into warmer season

Henning Westerholt
Summer in Berlin is definitely better than Winter in Bruessel

CfP and more details about Kamailio World 2023 should be published at beginning of 2023

Víctor Seva
I'm in the train. So, connection will drop from time to time :)

anything else that somebody wants to discuss as part of devel meeting?
if not, then we can end it and switch to free discussion (will not be in the transcripts on wiki)
thank you everyone!