irc-meetings/2023a.md: update transcript

docs/devel/irc-meetings/2023a.md

@@ -85,4 +85,245 @@ Collaborative Projects:
 
 ## Transcript
 
-TBA
+| time (-0500 EST) | matrix user | content |
+| --- | --- | --- |
+|10:17:25|@miconda:matrix.kamailio.dev|Sorry, still 5min|
+|10:24:24|@miconda:matrix.kamailio.dev|ready to start|
+|10:24:36|@miconda:matrix.kamailio.dev|sorry again for the delay!|
+|10:24:57|@miconda:matrix.kamailio.dev|Hello everybody!|
+|10:25:31|@miconda:matrix.kamailio.dev|a little bit of an agenda at: https://github.com/kamailio/kamailio-wiki/blob/main/docs/devel/irc-meetings/2023a.md|
+|10:27:42|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|the most topic debated so far was about obsoleting a group of modules|
+|10:28:40|@miconda:matrix.kamailio.dev|feedback on mailing list showed that some are still used|
+|10:29:29|@miconda:matrix.kamailio.dev|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|@henning:matrix.kamailio.dev|A warning for such that are still used is surely a good idea, e.g. for one release period|
+|10:30:00|@miconda:matrix.kamailio.dev|that might even be something like don't start kamailio unless some (new) core parameter or modparam is set|
+|10:30:06|@henning:matrix.kamailio.dev|and then we could remove them|
+|10:30:12|@henning:matrix.kamailio.dev|also possible, strict warning :)|
+|10:31:18|@miconda:matrix.kamailio.dev|not sure if we should keep the list of such modules in the core and check as core loads modules|
+|10:31:28|@miconda:matrix.kamailio.dev|or have the code in each such module|
+|10:31:55|@vseva:matrix.kamailio.dev|a warning in each module seems fine to me|
+|10:32:03|@miconda:matrix.kamailio.dev|ok|
+|10:32:13|@henning:matrix.kamailio.dev||
+|10:33:15|@fred:matrix.lod.com|Trying to remember which modules these were...|
+|10:34:12|@miconda:matrix.kamailio.dev|here is the email announcing them: https://kamailio.org/mailman3/hyperkitty/list/[email protected]/message/56MTKAXALSMBPFCA4KRMUQPJXMU65XLV/|
+|10:34:13|@fred:matrix.lod.com|Found them|
+|10:35:01|@henning:matrix.kamailio.dev|there have been not much feedback on the list|
+|10:35:03|@miconda:matrix.kamailio.dev|with the correction that uri_db was mistakenly added there|
+|10:35:12|@henning:matrix.kamailio.dev||
+|10:35:17|@fred:matrix.lod.com||
+|10:35:32|@henning:matrix.kamailio.dev| * there have been not much feedback on the list - so its probably fine for the people|
+|10:36:36|@miconda:matrix.kamailio.dev|ok, so we will follow up on mailing list on this topic|
+|10:37:01|@miconda:matrix.kamailio.dev|the second one coming out of Dusseldorf was the introduction of github actions for some automatic management of issues and PRs|
+|10:37:30|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|initially we thought it was already possible, but proved not to be, luckily Victor found some solution|
+|10:38:20|@henning:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|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:16|@fred:matrix.lod.com||
+|10:39:19|@miconda:matrix.kamailio.dev|it was done in a let's try fashion, because time in Dusseldorf was only 2 days|
+|10:39:52|@miconda:matrix.kamailio.dev|and they were not closed, it was first coming as a "reminder" that they were stale|
+|10:40:35|@miconda:matrix.kamailio.dev|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|@vseva:matrix.kamailio.dev|remember that ``bug`` tag keeps them open|
+|10:41:12|@fred:matrix.lod.com|Right now it's 42 days before stale, right? Seems fine|
+|10:41:18|@henning:matrix.kamailio.dev|I marked a few ones to work on it and re-open/keep open already|
+|10:41:22|@miconda:matrix.kamailio.dev|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:41:35|@henning:matrix.kamailio.dev||
+|10:42:05|@fred:matrix.lod.com|I think how the job is now works good... an improvement for sure.|
+|10:43:30|@miconda:matrix.kamailio.dev|ok ... anyhow, this work flow can be tuned at any time, just make suggestions via tracker or mailing lists|
+|10:44:26|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|and 2nd step: simply destroy everything about caring of locks/mutexes, or others needing to access local records|
+|10:47:26|@miconda:matrix.kamailio.dev|no change was done in Dusseldorf, this would require updates of the structures for module exports|
+|10:47:52|@miconda:matrix.kamailio.dev|but it is good to be aware of and eventually report cases when such change would be useful|
+|10:48:20|@miconda:matrix.kamailio.dev|it a good task to do at a future in-person meeting, if meanwhile is considered good to have|
+|10:48:28|@vseva:matrix.kamailio.dev|``shutdown gracefully``|
+|10:48:56|@werebear73:matrix.org||
+|10:49:23|@vseva:matrix.kamailio.dev|yes, it would imply some changes. Maybe a online meeting??|
+|10:49:39|@miconda:matrix.kamailio.dev|that's an option as well|
+|10:50:05|@vseva:matrix.kamailio.dev|we should try to organize a kind of hands-on online meeting |
+|10:50:11|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|my guess is that Juha uses a different flavour than the default one|
+|10:50:45|@henning:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|the real question is if there is still different behaviour inside the code|
+|10:51:28|@miconda:matrix.kamailio.dev|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|@henning:matrix.kamailio.dev|agree|
+|10:52:09|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|with flavour=kamailio, not finding $xyz should be considered an error|
+|10:53:32|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|ok, so probably the first step is to ask on mailing list, as proposed above|
+|10:54:08|@miconda:matrix.kamailio.dev|then see whre it leads based on feeback|
+|10:54:27|@vseva:matrix.kamailio.dev||
+|10:54:44|@miconda:matrix.kamailio.dev|another discussion in Dusseldorf was about eventual alternative to the "makefiles", maybe cmake|
+|10:55:17|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|but nothing was coming out of the past discussions|
+|10:56:06|@vseva:matrix.kamailio.dev|someone has to do the work and there's a lot of details in the Makefiles|
+|10:56:08|@miconda:matrix.kamailio.dev|anyone, one conclusion was that maybe we should review supported gcc versions, because they make the makefiles quite big now|
+|10:56:20|@miconda:matrix.kamailio.dev|as well as other compilers like suncc and icc|
+|10:56:38|@henning:matrix.kamailio.dev|this is a good idea to remove the really old gcc versions, like 2.9.x etc..|
+|10:56:46|@henning:matrix.kamailio.dev|3.x, 4.x|
+|10:56:58|@miconda:matrix.kamailio.dev|for gcc, either remove the extremely old ones, or try to join those that set similar options|
+|10:57:26|@miconda:matrix.kamailio.dev|yes, 2.x and 3.x could be good candidates for removing|
+|10:58:13|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|centos 6?!?|
+|11:00:13|@miconda:matrix.kamailio.dev|nex and probably last one from Dusseldorf, more for information ...|
+|11:00:36|@miconda:matrix.kamailio.dev|the addition of pre-commit hooks that could help formatting the code, removing trailing whitespaces, etc ...|
+|11:00:48|@miconda:matrix.kamailio.dev|if you missed the email about it, here it is: https://kamailio.org/mailman3/hyperkitty/list/[email protected]/message/7PSVLEKOMSCDMUYN4VZLIO4ZBRBJXMF6/|
+|11:01:04|@miconda:matrix.kamailio.dev|same one was sent to sr-users|
+|11:02:07|@vseva:matrix.kamailio.dev|hope it's helping|
+|11:02:43|@vseva:matrix.kamailio.dev|you can always skip checks with ``SKIP=<name>`` too|
+|11:03:00|@miconda:matrix.kamailio.dev|<name> being the id of the check?|
+|11:03:06|@vseva:matrix.kamailio.dev|yes|
+|11:03:54|@miconda:matrix.kamailio.dev|to conclude on Dusseldorf meeting, if I missed something relevant from there, anyone that participated just write the topic here|
+|11:04:50|@miconda:matrix.kamailio.dev|ok, then next ...|
+|11:05:19|@miconda:matrix.kamailio.dev|open issue, more from the perspective of someone here knowing about issues not reported yet (open on your side)|
+|11:05:51|@miconda:matrix.kamailio.dev|from the reported ones, it seems there are cases of crashes when tls with libssl 3.x is used|
+|11:06:16|@vseva:matrix.kamailio.dev|I'm having that  TLS + openssl 3 issue in a customer right now :-(|
+|11:06:28|@vseva:matrix.kamailio.dev|double free|
+|11:06:37|@miconda:matrix.kamailio.dev|trying to investigate, but it's not easy as crashing happen at tls layer (e.g., encryption negotiation)|
+|11:08:18|@miconda:matrix.kamailio.dev|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|@vseva:matrix.kamailio.dev|tlsa didn't help|
+|11:08:51|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|anyhow, I added a core parameter in kamailio (master) that will allow to specify extra size for each allocated chunk|
+|11:09:57|@miconda:matrix.kamailio.dev|so at least one can protect in case off by 1-byte writes are discovered/reported in logs|
+|11:10:44|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|so next topic ...|
+|11:12:33|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|lifting load from administrative point of view is always good|
+|11:14:07|@fred:matrix.lod.com||
+|11:14:49|@fred:matrix.lod.com|I think what we have now works... I don't know what the slack area is like though|
+|11:15:03|@fred:matrix.lod.com|I also don't know if anyone still uses IRC|
+|11:15:05|@vseva:matrix.kamailio.dev|I'm fine with what we got|
+|11:15:16|@vseva:matrix.kamailio.dev|I'm connected to IRC... just silence there|
+|11:15:33|@miconda:matrix.kamailio.dev|ok -- and yes, maybe we can remove references to irc on the website|
+|11:15:44|@fred:matrix.lod.com|Great idea|
+|11:15:52|@henning:matrix.kamailio.dev||
+|11:15:57|@miconda:matrix.kamailio.dev|if they are still uses, they can stay as just community|
+|11:16:11|@henning:matrix.kamailio.dev||
+|11:16:11|@devopsec:matrix.org|i moved to matrix since irc was dead, no problems with matrix though|
+|11:16:50|@fred:matrix.lod.com|I'm happy with matrix most days ;)|
+|11:16:51|@miconda:matrix.kamailio.dev|then we can move on to releases|
+|11:17:18|@miconda:matrix.kamailio.dev|(keeping a high pace, since I was late and some might have to leave early)|
+|11:17:34|@miconda:matrix.kamailio.dev|minors from 5.6 and 5.7 were out pretty recently|
+|11:18:06|@miconda:matrix.kamailio.dev|probably a new one from 5.7 will happen in a matter of weeks, for 5.6 sometime later|
+|11:18:09|@marrold:matrix.org||
+|11:18:31|@miconda:matrix.kamailio.dev|for a major release, I am not sure yet when|
+|11:19:10|@miconda:matrix.kamailio.dev|we could try a 5.8 in 2024 somehow earlier than usual, let's say to aim for march|
+|11:19:41|@miconda:matrix.kamailio.dev| * we could try a 5.8 in 2024 somehow earlier than usual, let's say to aim for March|
+|11:20:02|@henning:matrix.kamailio.dev|5.7.0 was in May this year|
+|11:20:09|@miconda:matrix.kamailio.dev|that could be good if we want to go afterwards for a 6.0 with some major changes|
+|11:20:45|@miconda:matrix.kamailio.dev|yes, we ended up releasing like May or June lately, like 1 year time frames in between|
+|11:20:52|@vseva:matrix.kamailio.dev||
+|11:22:05|@miconda:matrix.kamailio.dev|probably we can decide at the begining of the next year, after the season holidays, maybe we can plan it better|
+|11:22:52|@fred:matrix.lod.com|I'd love to move on to 6... but agree there should be something major for that change.|
+|11:23:03|@henning:matrix.kamailio.dev||
+|11:23:59|@miconda:matrix.kamailio.dev|ok, so let's leave it for mailing lists|
+|11:24:39|@miconda:matrix.kamailio.dev|on server administration side I think we are ok ... is debian 11 still maintained?|
+|11:25:19|@miconda:matrix.kamailio.dev|or we have some pressure to migrate to debian 12?!?|
+|11:25:31|@fred:matrix.lod.com|no pressure yet I hope|
+|11:25:33|@fred:matrix.lod.com|;)|
+|11:26:00|@fred:matrix.lod.com|July 2024|
+|11:26:28|@miconda:matrix.kamailio.dev|ok, still time|
+|11:26:42|@fred:matrix.lod.com|Oh wait, thats 10|
+|11:26:46|@fred:matrix.lod.com|even longer =)|
+|11:26:55|@fred:matrix.lod.com|June 2026|
+|11:26:55|@henning:matrix.kamailio.dev||
+|11:27:07|@vseva:matrix.kamailio.dev|https://wiki.debian.org/LTS|
+|11:27:24|@henning:matrix.kamailio.dev||
+|11:27:48|@vseva:matrix.kamailio.dev|image.png|
+|11:28:34|@vseva:matrix.kamailio.dev|no real rush but I would try to move to bookworm|
+|11:28:39|@devopsec:matrix.org|just a side note, this tool this awesome for checking EOL dates, here is the debian entry https://endoflife.date/debian|
+|11:29:33|@vseva:matrix.kamailio.dev|I think the hard part was already done migrating the mailman|
+|11:29:38|@fred:matrix.lod.com|speaking of fun url's.... https://rtfm.tel/kamailio ;)|
+|11:30:27|@miconda:matrix.kamailio.dev|yep, hopefully debian 11 to 12 is going to be easier than 10 to 11|
+|11:30:40|@fred:matrix.lod.com|I need to move kama3 to 11|
+|11:30:57|@miconda:matrix.kamailio.dev|removal of python2 brought some headaches with many apps, including unavailability of mailman2|
+|11:31:30|@miconda:matrix.kamailio.dev|next one then ...|
+|11:31:50|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|otherwise I haven't spotted more proposals to discuss|
+|11:33:43|@vseva:matrix.kamailio.dev|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|@henning:matrix.kamailio.dev|we could switch to C++ :D|
+|11:34:15|@vseva:matrix.kamailio.dev|so I can later go module by module and do it|
+|11:35:48|@miconda:matrix.kamailio.dev|it's how was done while porting some patches from an external (cloned) repository|
+|11:35:59|@miconda:matrix.kamailio.dev|if you look at ims_qos module, it has now:|
+|11:36:32|@miconda:matrix.kamailio.dev|ims_qos_params_t _imsqos_params = { .recv_mode = 0, .dlg_direction = DLG_MOBILE_REGISTER};|
+|11:37:08|@miconda:matrix.kamailio.dev|with:|
+|11:37:09|@miconda:matrix.kamailio.dev|typedef struct ims_qos_params `{int recv_mode;int dlg_direction;}ims_qos_params_t;`|
+|11:37:36|@miconda:matrix.kamailio.dev|for everybody else, this is actually also from in-person Dusseldorf meeting|
+|11:37:51|@miconda:matrix.kamailio.dev|a discussion about how to avoid global variables conflicts|
+|11:38:23|@miconda:matrix.kamailio.dev|because sometimes it happens different modules have same global variables for similar purposes, like the db_url|
+|11:38:33|@vseva:matrix.kamailio.dev|ACK. I didn't noticed. Thanks!|
+|11:39:03|@vseva:matrix.kamailio.dev|I will try to work on that on my spare time|
+|11:39:33|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|the use of db_url is to give the example here|
+|11:41:05|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|so I took that approach when I ported some stuff for ims_qos module from an external repo|
+|11:41:51|@henning:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|yes, we prefix with the module name, that's ok, but some PRs come without|
+|11:43:58|@miconda:matrix.kamailio.dev|maybe it would be better if the external contributors discover we use a structure for modparams and they add fields there|
+|11:44:13|@miconda:matrix.kamailio.dev|anyhow, this was just a proposal, not something that must to be done|
+|11:44:37|@miconda:matrix.kamailio.dev|it was considered good to use such approach in the future, for new params, ...|
+|11:44:58|@miconda:matrix.kamailio.dev|of course, if one wants to do it for own modules, it's fine|
+|11:45:25|@vseva:matrix.kamailio.dev|If we have it... people will just add new parameters the same way|
+|11:45:46|@miconda:matrix.kamailio.dev|yes, that would be the scope|
+|11:46:34|@henning:matrix.kamailio.dev|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|@henning:matrix.kamailio.dev|and of course its a major effort in the end unfortunately|
+|11:47:40|@henning:matrix.kamailio.dev|So its probably not realistic|
+|11:47:58|@vseva:matrix.kamailio.dev|I would prefer to use glib instead :-)|
+|11:48:46|@henning:matrix.kamailio.dev|something like boost would be of course great. No personal experience with glib from my side, though|
+|11:49:32|@miconda:matrix.kamailio.dev|is glib on *BSD? if I am not wrong thinking g comes from GNU?!?|
+|11:50:33|@henning:matrix.kamailio.dev|	LGPL-2.1-or-later|
+|11:51:03|@miconda:matrix.kamailio.dev|is LGPL, so probably *BSD guys have nothing againt it, like they usually have against pure GPL software :-)|
+|11:51:39|@miconda:matrix.kamailio.dev|anyhow, I am not familiar with as well, if found useful somewhere, it can be considered of course|
+|11:51:50|@miconda:matrix.kamailio.dev|I think rtpengine uses it extensively ...|
+|11:52:32|@vseva:matrix.kamailio.dev|https://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/glib2/index.html|
+|11:52:33|@henning:matrix.kamailio.dev|yes,  its used from rtpengine|
+|11:52:45|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|it's like 1h30min since we started ... time flies quickly ...|
+|11:54:43|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev| * 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|@miconda:matrix.kamailio.dev|iirc, one was used more by Sergey for rpms (?!?), the other one was more for debs|
+|11:56:41|@miconda:matrix.kamailio.dev|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|@vseva:matrix.kamailio.dev|I did some work to keep what it was running... I've not response from Sergey|
+|11:58:09|@miconda:matrix.kamailio.dev|ok|
+|11:58:44|@miconda:matrix.kamailio.dev|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|@vseva:matrix.kamailio.dev| * I did some work to keep what it was running... I've no response from Sergey|
+|11:59:32|@miconda:matrix.kamailio.dev|if not, we can end the official devel meeting and start free discussions (not in transcript)|
+|12:00:01|@vseva:matrix.kamailio.dev|Thanks to everyone|
+|12:00:18|@miconda:matrix.kamailio.dev|Thanks all!|
+|12:00:36|@fred:matrix.lod.com|Thank you all for all that you do.|
+|12:01:04|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|then free discussions ...|
+|12:01:38|@miconda:matrix.kamailio.dev|what's new and worth discussing from RTC space|
+|12:01:48|@miconda:matrix.kamailio.dev| * what's new and worth discussing from RTC space?!?|
+|12:02:48|@miconda:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|btw, FOSDEM 2024 has again an RTC devroom: https://lists.fosdem.org/pipermail/fosdem/2023q4/003518.html|
+|12:03:59|@fred:matrix.lod.com|The matrix change should be fun ;)|
+|12:04:06|@miconda:matrix.kamailio.dev|not sure I can go at this edition, I will try, but I don't know at this moment|
+|12:05:12|@miconda:matrix.kamailio.dev|is matrix now AGPL? or what they changed to? I think I saw it but I forgot  ...|
+|12:06:18|@fred:matrix.lod.com|the new forks will use AGPLv3|
+|12:06:33|@fred:matrix.lod.com|with a contributor license agreement|
+|12:07:02|@fred:matrix.lod.com|They still haven't described how/when forks will happen, so upgrading is still unknown.|
+|12:07:32|@henning:matrix.kamailio.dev|interesting development|
+|12:07:44|@fred:matrix.lod.com|[Matrix announcement](https://element.io/blog/element-to-adopt-agplv3/)|
+|12:09:16|@miconda:matrix.kamailio.dev|we can go back to IRC if matrix derails :-)|
+|12:09:54|@fred:matrix.lod.com|xmpp ;)|
+|12:11:23|@henning:matrix.kamailio.dev|regarding open source support, I've had some discussion about similar topics some weeks ago with the homer guys https://github.com/sipcapture/homer-ui/issues/627|
+|12:12:32|@henning:matrix.kamailio.dev|unfortunately it seems not many companies support their open source development efforts|
+|12:13:57|@henning:matrix.kamailio.dev|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|@miconda:matrix.kamailio.dev|is H 10 out? or work in progress (eta in such case)?|
+|12:15:15|@fred:matrix.lod.com|This just reminded me how much I love SIPDUMP by the way|
+|12:16:25|@miconda:matrix.kamailio.dev| - sipdump for tls is magnificent ... + sngrep|
+|12:19:28|@vseva:matrix.kamailio.dev|I forgot about kamcmd => kamcli|
+|12:19:55|@vseva:matrix.kamailio.dev| * I forgot about kamcmd/kamctl => kamcli|
+|12:19:56|@henning:matrix.kamailio.dev|homer 10 is still in development|
+|12:20:00|@miconda:matrix.kamailio.dev|that's something we discuseed at past editions, so I haven't put it back on table|
+|12:20:56|@miconda:matrix.kamailio.dev|maybe we could "forget" old tools when starting a fresh 6.x series :-)|
+|12:21:07|@vseva:matrix.kamailio.dev||
+|12:21:39|@vseva:matrix.kamailio.dev|I've to leave. See you!|
+|12:22:19|@miconda:matrix.kamailio.dev|Thanks! Bye!|
+|12:22:58|@miconda:matrix.kamailio.dev|Soon I'll have to hunt something for dinner as well ...|
+|12:24:43|@miconda:matrix.kamailio.dev|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!|
+