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.

Date:

  • 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

Place:

Utilities:

Participants

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

Agenda

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:
  • https://github.com/kamailio/kamailio/issues/
  • packaging and distributions
  • continuous integration
  • use of github actions

Administration:

  • 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

Documentation:

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

Collaborative Projects:

  • unit testing, documentation, etc.
  • community announcements

Transcript

Thu, Dec 8 2022

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

miconda starting devel meeting in about 10min

oej Ready with a cup of tea

Víctor Seva (hi)

Henning Westerholt Hello

miconda 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: 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

miconda 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 https://www.kamailio.org/wikidocs/cookbooks/devel/core/#return_mode 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 AFAIK nothing against it, just need to be considered

miconda 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

miconda 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

miconda 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

miconda 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

miconda 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!

Henning Westerholt It was a great re-start indeed

miconda 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 https://github.com/kamailio/kamailio/issues/3274 -> anyone encountered this too?

miconda 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

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

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

miconda 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

miconda 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

miconda 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

miconda 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.

miconda 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

miconda ok 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

miconda 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

miconda https://rpm.kamailio.org/

Henning Westerholt ah, you are right, my fault

miconda 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

miconda 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

miconda ok

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

miconda 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

miconda 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

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

Víctor Seva One commit per module

miconda 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

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

Henning Westerholt yes

miconda anything else for GH actions?

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

miconda 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

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

miconda 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

miconda 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

miconda 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

miconda 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

miconda 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

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

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

miconda 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 etc..

miconda 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

miconda @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

miconda 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

miconda 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?

miconda 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

miconda 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 :)

miconda 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) 3 2 1 thank you everyone!