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
- Matrix chat room: #kamailio:matrix.kamailio.dev
- To join as a guest:
- go to: https://riot.kamailio.dev/#/welcome
- click on Room Directory
- then click on kamailio room to join it
- Time Converter
- Matrix resources
- website: https://matrix.org/
- it allows public registrations for getting a Matrix user account
- client applications: https://matrix.org/clients
- unofficial list of other public matrix servers: https://www.anchel.nl/matrix-publiclist/
- website: https://matrix.org/
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
- anything relevant that is missing?
- updates for wiki with markdown and mkdocs (github markdown)
- 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
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: https://github.com/kamailio/kamailio-wiki/blob/main/docs/devel/irc-meetings/2022a.md#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 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
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
here I am sorry, busy afternoon :)
yes, we have deployed the new jansson function and everything works and no issue to report
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
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?
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
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 sipgate.de, 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!
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 ...
kamcmd is broken since a long time, like years
but as you wrote, there are alternatives for sure
https://github.com/kamailio/kamailio/issues/3274 -> anyone encountered this too?
not using python myself -- do you need 2.7? have you tried with 3.x?
not tried, will do
on newer distributions app_python(2) is not available anymore anyway
speaking of that, I actually just added app_python3s module ;)
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
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
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
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
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
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
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 ...
the rpm service is AFAIK only for CentOS
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
yes, I looked into it
or codeql is something different
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
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 ...
It would be nice to have a clang format check
you mean, like for coding style? or for correctness
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
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
One commit per module
I think some were concerned about tracking changes (Henning?!?) ...
like when using git blame ...
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
anything else for GH actions?
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 kamailio.org
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
sounds like a good plan, update would be nice
I think mail is more than enough notice
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
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
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?
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 ...
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?
coding style of modules? its more an internal topic, probably not that relevant for users
yep, but as reference, about contribution styles ...
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
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 ...
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) ...
might be also a larger change with some impact on merging/code structure
not sure if oej is still around at this time ...
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?
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
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)
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
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
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!