Online Devel Meeting - 2023-12-05

Note: the online meeting is planned to be hosted on a Matrix room. See more details below.


  • Proposed: 15:00 UTC, Tuesday, Dec 05, 2023
  • can attend: dcm, vseva, qxork, ...
  • 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
  • qxork - Fred Posner


Kamailio Development Status:

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


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

Kamailio 5.8 (next major release):

  • aim for 5.8 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


time (-0500 EST) matrix user content
10:17:25 Sorry, still 5min
10:24:24 ready to start
10:24:36 sorry again for the delay!
10:24:57 Hello everybody!
10:25:31 a little bit of an agenda at:
10:27:42 hopefully those interested in the meetings are still around, so, the first topic would be the follow up after the Dusseldorf in-person meeting
10:28:17 the most topic debated so far was about obsoleting a group of modules
10:28:40 feedback on mailing list showed that some are still used
10:29:29 so I am considering to split the group of proposed obsoleted modules in two, one to be very soon relocated to a dedicated repo, and another one that should be kept for a while, but with an explicit warning
10:29:58 A warning for such that are still used is surely a good idea, e.g. for one release period
10:30:00 that might even be something like don't start kamailio unless some (new) core parameter or modparam is set
10:30:06 and then we could remove them
10:30:12 also possible, strict warning :)
10:31:18 not sure if we should keep the list of such modules in the core and check as core loads modules
10:31:28 or have the code in each such module
10:31:55 a warning in each module seems fine to me
10:32:03 ok
10:33:15 Trying to remember which modules these were...
10:34:12 here is the email announcing them:
10:34:13 Found them
10:35:01 there have been not much feedback on the list
10:35:03 with the correction that uri_db was mistakenly added there
10:35:32 * there have been not much feedback on the list - so its probably fine for the people
10:36:36 ok, so we will follow up on mailing list on this topic
10:37:01 the second one coming out of Dusseldorf was the introduction of github actions for some automatic management of issues and PRs
10:37:30 that brought also some discussions, I think at this moment we are good with the process, having options to reopen such closed items
10:37:57 initially we thought it was already possible, but proved not to be, luckily Victor found some solution
10:38:20 there were some feedback of surprised users, it would be good next time when we change something like this to announce it before ;-)
10:38:34 what could be done is tuning, for example the time lines, if someone thinks that it is too short 6 weeks to stale + 2 weeks to closing
10:39:19 it was done in a let's try fashion, because time in Dusseldorf was only 2 days
10:39:52 and they were not closed, it was first coming as a "reminder" that they were stale
10:40:35 anyhow I am going to review and probably open several that I had in mind to investigate, but didn't find the time for
10:41:07 remember that bug tag keeps them open
10:41:12 Right now it's 42 days before stale, right? Seems fine
10:41:18 I marked a few ones to work on it and re-open/keep open already
10:41:22 we anyhow wrote in many feature requests that the might be closed after one month of so, but then nobody look over them again
10:42:05 I think how the job is now works good... an improvement for sure.
10:43:30 ok ... anyhow, this work flow can be tuned at any time, just make suggestions via tracker or mailing lists
10:44:26 another topic that should be propagated to larger community was about the eventual need of making application shut down in two steps
10:45:21 apparently there are crashes at shut down because some modules depend on the other and one can destroy its records but other ones may still need to access them
10:46:20 to be like prepare-to-shutdown: when the module should write to db or other sync tasks, but still keep its records/structures in memory
10:46:53 and 2nd step: simply destroy everything about caring of locks/mutexes, or others needing to access local records
10:47:26 no change was done in Dusseldorf, this would require updates of the structures for module exports
10:47:52 but it is good to be aware of and eventually report cases when such change would be useful
10:48:20 it a good task to do at a future in-person meeting, if meanwhile is considered good to have
10:48:28 shutdown gracefully
10:49:23 yes, it would imply some changes. Maybe a online meeting??
10:49:39 that's an option as well
10:50:05 we should try to organize a kind of hands-on online meeting
10:50:11 also from Dusseldorf: analyzing the impact of FLAVOUR that can be set in the Makefiles, now defaulting to kamailio, but can be also ser or sip-router, iirc
10:50:33 my guess is that Juha uses a different flavour than the default one
10:50:45 I wondered already a few times if we could not remove the FLAVOUR, maybe ask on the list if people are still using it
10:50:56 the real question is if there is still different behaviour inside the code
10:51:28 keeping the option to compile with different binary name could be fine, but if the behaviour changes, then we have to clean that somehow
10:52:02 agree
10:52:09 iirc, one of the reasons was that if $xyz is not found as pseudo-variable, then the flavour=ser would consider that an avp, like $avp(xyz)
10:52:45 with flavour=kamailio, not finding $xyz should be considered an error
10:53:32 but that was proposed during 2009-2010 merge, I haven't done this part of the merge and I am not sure how it ended up, as I using onli flavour=kamailio
10:53:56 ok, so probably the first step is to ask on mailing list, as proposed above
10:54:08 then see whre it leads based on feeback
10:54:44 another discussion in Dusseldorf was about eventual alternative to the "makefiles", maybe cmake
10:55:17 I think we discussed the topic in the past, like everyone would be ok to switch to something else if proves to be easier to maintain
10:55:34 but nothing was coming out of the past discussions
10:56:06 someone has to do the work and there's a lot of details in the Makefiles
10:56:08 anyone, one conclusion was that maybe we should review supported gcc versions, because they make the makefiles quite big now
10:56:20 as well as other compilers like suncc and icc
10:56:38 this is a good idea to remove the really old gcc versions, like 2.9.x etc..
10:56:46 3.x, 4.x
10:56:58 for gcc, either remove the extremely old ones, or try to join those that set similar options
10:57:26 yes, 2.x and 3.x could be good candidates for removing
10:58:13 4.x - I think there are some distro still using them, in the way that those distros might not be maintained, but people still run them
10:58:24 centos 6?!?
11:00:13 nex and probably last one from Dusseldorf, more for information ...
11:00:36 the addition of pre-commit hooks that could help formatting the code, removing trailing whitespaces, etc ...
11:00:48 if you missed the email about it, here it is:
11:01:04 same one was sent to sr-users
11:02:07 hope it's helping
11:02:43 you can always skip checks with SKIP=<name> too
11:03:00 being the id of the check?
11:03:06 yes
11:03:54 to conclude on Dusseldorf meeting, if I missed something relevant from there, anyone that participated just write the topic here
11:04:50 ok, then next ...
11:05:19 open issue, more from the perspective of someone here knowing about issues not reported yet (open on your side)
11:05:51 from the reported ones, it seems there are cases of crashes when tls with libssl 3.x is used
11:06:16 I'm having that TLS + openssl 3 issue in a customer right now :-(
11:06:28 double free
11:06:37 trying to investigate, but it's not easy as crashing happen at tls layer (e.g., encryption negotiation)
11:08:18 because in some cases I noticed errors related to memory chunk tail overwritten, I thought there could be a buffer overflow, which might not be in the kamailio code, but in external libraries (like libmysqlclient or libcurl)
11:08:21 tlsa didn't help
11:08:51 I haven't looked at this libs to see if they reported such bugs for some of their older version that might be deployed on distros
11:09:20 anyhow, I added a core parameter in kamailio (master) that will allow to specify extra size for each allocated chunk
11:09:57 so at least one can protect in case off by 1-byte writes are discovered/reported in logs
11:10:44 so if no other ones to report right now, we have to dive deeper in the one related to tls and libssl 3.x
11:10:55 so next topic ...
11:12:33 communication channels: I think we should move from mailing list forums, not to be the last ones using mailing lists ... ok this just a joke, as I saw some hot discussions on such topic in other projects ...
11:13:20 but, as usual, if one wants to suggest new tools for making the interaction easier, simplify workflow, just do it at any time
11:13:41 lifting load from administrative point of view is always good
11:14:49 I think what we have now works... I don't know what the slack area is like though
11:15:03 I also don't know if anyone still uses IRC
11:15:05 I'm fine with what we got
11:15:16 I'm connected to IRC... just silence there
11:15:33 ok -- and yes, maybe we can remove references to irc on the website
11:15:44 Great idea
11:15:57 if they are still uses, they can stay as just community
11:16:11 i moved to matrix since irc was dead, no problems with matrix though
11:16:50 I'm happy with matrix most days ;)
11:16:51 then we can move on to releases
11:17:18 (keeping a high pace, since I was late and some might have to leave early)
11:17:34 minors from 5.6 and 5.7 were out pretty recently
11:18:06 probably a new one from 5.7 will happen in a matter of weeks, for 5.6 sometime later
11:18:31 for a major release, I am not sure yet when
11:19:10 we could try a 5.8 in 2024 somehow earlier than usual, let's say to aim for march
11:19:41 * we could try a 5.8 in 2024 somehow earlier than usual, let's say to aim for March
11:20:02 5.7.0 was in May this year
11:20:09 that could be good if we want to go afterwards for a 6.0 with some major changes
11:20:45 yes, we ended up releasing like May or June lately, like 1 year time frames in between
11:22:05 probably we can decide at the begining of the next year, after the season holidays, maybe we can plan it better
11:22:52 I'd love to move on to 6... but agree there should be something major for that change.
11:23:59 ok, so let's leave it for mailing lists
11:24:39 on server administration side I think we are ok ... is debian 11 still maintained?
11:25:19 or we have some pressure to migrate to debian 12?!?
11:25:31 no pressure yet I hope
11:25:33 ;)
11:26:00 July 2024
11:26:28 ok, still time
11:26:42 Oh wait, thats 10
11:26:46 even longer =)
11:26:55 June 2026
11:27:48 image.png
11:28:34 no real rush but I would try to move to bookworm
11:28:39 just a side note, this tool this awesome for checking EOL dates, here is the debian entry
11:29:33 I think the hard part was already done migrating the mailman
11:29:38 speaking of fun url's.... ;)
11:30:27 yep, hopefully debian 11 to 12 is going to be easier than 10 to 11
11:30:40 I need to move kama3 to 11
11:30:57 removal of python2 brought some headaches with many apps, including unavailability of mailman2
11:31:30 next one then ...
11:31:50 from the mailing list, when this meeting was announced, someone proposed about handling REFER, this being more like a feature request: while it may not require a full b2bua behaviour, it should need a new module to track sdps and parties involved in call ... so, as usual, some development. Personally I don't have a need for it
11:32:36 otherwise I haven't spotted more proposals to discuss
11:33:43 about the changes needed to isolate global variables in modules ... can you please provide an example of what you would like things to be?
11:34:01 we could switch to C++ :D
11:34:15 so I can later go module by module and do it
11:35:48 it's how was done while porting some patches from an external (cloned) repository
11:35:59 if you look at ims_qos module, it has now:
11:36:32 ims_qos_params_t _imsqos_params = { .recv_mode = 0, .dlg_direction = DLG_MOBILE_REGISTER};
11:37:08 with:
11:37:09 typedef struct ims_qos_params {int recv_mode;int dlg_direction;}ims_qos_params_t;
11:37:36 for everybody else, this is actually also from in-person Dusseldorf meeting
11:37:51 a discussion about how to avoid global variables conflicts
11:38:23 because sometimes it happens different modules have same global variables for similar purposes, like the db_url
11:38:33 ACK. I didn't noticed. Thanks!
11:39:03 I will try to work on that on my spare time
11:39:33 however, in some cases, because symbols are made globals when opening the .so files, they can conflict, the linker may find first the db_url global variable of another module ...
11:39:52 the use of db_url is to give the example here
11:41:05 one of the proposals in Dusseldorf was to create a structure to collect parameters and have one global variable for that structure with a name specific to the module
11:41:25 so I took that approach when I ported some stuff for ims_qos module from an external repo
11:41:51 usually we prefix the module name or a part of the module name as part of the variable, e.g. cr_db_url (carrierroute) etc..
11:42:45 for more context, I met the guy that wrote those patches at an event a few months ago and I said I could help to port them to our master branch, because they were done for 5.3.x
11:43:16 yes, we prefix with the module name, that's ok, but some PRs come without
11:43:58 maybe it would be better if the external contributors discover we use a structure for modparams and they add fields there
11:44:13 anyhow, this was just a proposal, not something that must to be done
11:44:37 it was considered good to use such approach in the future, for new params, ...
11:44:58 of course, if one wants to do it for own modules, it's fine
11:45:25 If we have it... people will just add new parameters the same way
11:45:46 yes, that would be the scope
11:46:34 My suggestion to use C++ was not completely meant as joke, this would help of course with this kind of global namespace issues. But of course it would be a serious change and we would need to really define the subset of C++ we want to use, otherwise its getting way to complex.
11:47:15 and of course its a major effort in the end unfortunately
11:47:40 So its probably not realistic
11:47:58 I would prefer to use glib instead :-)
11:48:46 something like boost would be of course great. No personal experience with glib from my side, though
11:49:32 is glib on *BSD? if I am not wrong thinking g comes from GNU?!?
11:50:33 LGPL-2.1-or-later
11:51:03 is LGPL, so probably *BSD guys have nothing againt it, like they usually have against pure GPL software :-)
11:51:39 anyhow, I am not familiar with as well, if found useful somewhere, it can be considered of course
11:51:50 I think rtpengine uses it extensively ...
11:52:33 yes, its used from rtpengine
11:52:45 as there are no major topics I can add here, everyone feel free to propose ... we can aproach in the order of posting ...
11:53:35 it's like 1h30min since we started ... time flies quickly ...
11:54:43 on packaging and docker, I think Victor wanted to merge some repos ... not sure if was sorted out somehow, whether is possible or note
11:54:48 * on packaging and docker, I think Victor wanted to merge some repos ... not sure if was sorted out somehow, whether is possible or not
11:55:20 iirc, one was used more by Sergey for rpms (?!?), the other one was more for debs
11:56:41 also, on ci/cd, as it seems that github actions are powerful, if anyone is aware of some that could bring more magic to kamailio work flows, just suggest them here or on mailing list
11:57:53 I did some work to keep what it was running... I've not response from Sergey
11:58:09 ok
11:58:44 anything else that one wants to discuss officially as part of the devel meeting (which means it can get in the transcript)
11:58:46 * I did some work to keep what it was running... I've no response from Sergey
11:59:32 if not, we can end the official devel meeting and start free discussions (not in transcript)
12:00:01 Thanks to everyone
12:00:18 Thanks all!
12:00:36 Thank you all for all that you do.
12:01:04 Once again sorry for keeping you waiting for me at the beginning, sometime a little snow and ice blocks Berlin at the end of working hours!
12:01:25 then free discussions ...
12:01:38 what's new and worth discussing from RTC space
12:01:48 * what's new and worth discussing from RTC space?!?
12:02:48 noticed some hot debates around Matrix changing the license and requiring CLA, ... Asterisk willing to close mailing lsits ... anything else that I missed?
12:03:43 btw, FOSDEM 2024 has again an RTC devroom:
12:03:59 The matrix change should be fun ;)
12:04:06 not sure I can go at this edition, I will try, but I don't know at this moment
12:05:12 is matrix now AGPL? or what they changed to? I think I saw it but I forgot ...
12:06:18 the new forks will use AGPLv3
12:06:33 with a contributor license agreement
12:07:02 They still haven't described how/when forks will happen, so upgrading is still unknown.
12:07:32 interesting development
12:07:44 Matrix announcement
12:09:16 we can go back to IRC if matrix derails :-)
12:09:54 xmpp ;)
12:11:23 regarding open source support, I've had some discussion about similar topics some weeks ago with the homer guys
12:12:32 unfortunately it seems not many companies support their open source development efforts
12:13:57 they also looking more into moving to homer 10, which would be basically use grafana to do some of the infrastruture stuff
12:15:06 is H 10 out? or work in progress (eta in such case)?
12:15:15 This just reminded me how much I love SIPDUMP by the way
12:16:25 - sipdump for tls is magnificent ... + sngrep
12:19:28 I forgot about kamcmd => kamcli
12:19:55 * I forgot about kamcmd/kamctl => kamcli
12:19:56 homer 10 is still in development
12:20:00 that's something we discuseed at past editions, so I haven't put it back on table
12:20:56 maybe we could "forget" old tools when starting a fresh 6.x series :-)
12:21:39 I've to leave. See you!
12:22:19 Thanks! Bye!
12:22:58 Soon I'll have to hunt something for dinner as well ...
12:24:43 I am going to check here from time to time in case something new pops up ... but I say bye now to those that are going to leave!