Online IRC Devel Meeting - 2020-11-25

Note: because freenode.net IRC service is now requiring user registration, this time the online meeting is planned to be hosted on a Matrix room where we can grant guest access and people can join via web browser. See more details below.

Date:

  • Proposed: 15:00 UTC, Wednesday, Nov 25, 2020
  • can attend: dcm, vseva, fposner, ...
  • 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:

Backup place:

  • IRC channel: #kamailio on irc.freenode.net server

Utilities:

Participants

Participation is open to anyone, just join the IRC channel if you want to participate.

People adding notes in the agenda using abbreviations:

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

Agenda

Kamailio Development Status:

Administration:

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

Kamailio 5.5 (next major release):

  • LREPRoxy module (Mojtaba)
  • roadmap
  • features
  • anything relevant that is missing?
  • priorities

Documentation:

  • tutorials/cookbooks -- wiki vs mkdocs (github markdown)

Collaborative Projects:

  • unit testing, documentation, etc.
  • community announcements

Transcript

All times in UTC (2020-11-25)

15:01:12 @miconda Hello! Starting in 5min, so more can join if they are a bit late. 15:07:03 @miconda ok, we should start 15:07:14 @joelsdc1 👋 15:07:44 @miconda link to wiki with agenda: https: 15:08:25 @miconda first, as usual, major or minor issues with Kamailio 15:08:43 @miconda anything not reported yet on bug tracker that should be announced here? 15:08:52 @khorsmann hi all 15:09:22 @miconda * Hello! Starting in 5min, so more can join if they are a bit late. 15:09:41 @vseva https://github.com/kamailio/kamailio/issues/2560 ? 15:10:23 @vseva I'm lost with this TLS 15:16:17 @miconda hmm, strange! 15:11:21 @jchavanton I think we should log the version of TLS used 15:11:54 @miconda I somehow missed it today, but it doesn't provide all logs 15:11:55 @jchavanton in the module init 15:12:40 @miconda last week I installed 2 webrtc-sip gateways with kamailio 5.4 on buster, with tls using let's encrypt certs and all was fine 15:12:52 @miconda tested with tryit jssip 15:13:20 @miconda Julien Chavanton: we can add more logs, sure, feel free to make PRs with what you want to add 15:14:18 @henning we are using kamailio 5.4 with TLS in many cases, no crashes and such 15:14:22 @henning on buster 15:16:08 @fred I'm not sure if that bug is related to an AWS build 15:16:47 @miconda we have to ask for more details, at least all logs printed from start up 15:17:02 @miconda and eventually a minimal config to reproduce 15:17:23 @miconda can just be an error with some modparam or even other module, because the tls logs are from shut down callback 15:17:32 @miconda is not showing any error related to tls itself 15:18:02 @miconda could be the well-known conflict with other libs already initializing the libssl 15:19:45 @miconda ok ... anything else? 15:20:43 @miconda if not, we can continue to the open issues, maybe we can review some of the old ones and decide what to do, before planning next minor releases 15:21:10 @miconda I linked the issues opened by oej (iirc) a while ago, related to packaging 15:21:53 @miconda but I understood from @vseva is not easy to change from version to version, at least for debian, because it requires the whole process to add new packages 15:22:14 @miconda I refer to https:github.com/kamailio/kamailio/issues/969 15:22:26 @oej That's an old issue... 15:23:08 @vseva it's fine for me just that we will have to wait in the NEW queue for a while, but that can be achieved on next version 15:23:21 @miconda indeed, iirc, we started the discussion about it at a FOSDEM 15:23:26 @vseva stable is almost on freeze already 15:23:51 @vseva * stable is almost on freeze already 15:23:53 @miconda I am fine with the current state 15:24:07 @miconda just discussing here to see what should be done 15:24:29 @miconda to get rid of very old issues there 15:26:32 @miconda so maybe we can just close this one and when one wants to refactor the packaging, then just make a pr, or start a new discussion with a proposal 15:27:18 @oej right 15:28:04 @miconda then I hope to get some time to see what can be done for dnssec 15:29:00 @miconda using the libdnsval was straightforwards, having drop in functions for the usual ones -- I mean about: https:github.com/kamailio/kamailio/issues/851 15:29:34 @miconda I looked a bit at other dnssec libs, but didn't find drop in functions, so likely needs writing some wrappers 15:29:48 @miconda so far I didn't get any request for dnssec 15:30:01 @miconda thus I was never pressured to do something 15:30:43 @miconda on the other hand, besides being removed from debian, libdnsval still got some updates lately, so doesn't seem to be completely abandoned 15:31:23 @miconda saying just in case one needs it now, should be able compile the module from sources 15:33:00 @miconda then looking at the last page of issues, Víctor Seva is going to be a bit busy checking what is still good to keep there :-) : https:github.com/kamailio/kamailio/issues?page=3 15:33:28 @henning hehe 15:34:34 @miconda nothing really critical, just soft reminder to review very old issues to see what is still actual 15:34:34 @vseva well, this one https://github.com/kamailio/kamailio/issues/668 is to be decided here 15:35:00 @miconda I think we do really good with number of open issues, most of them are requests for new features/enhancements anyhow 15:35:28 @henning we are really good with the number, think the same 15:36:50 @miconda Víctor Seva: yeah, with the wiki we should also decide what to do 15:37:06 @miconda we disabled write access after registration, due to spammers 15:37:31 @miconda so issue 668 can stay open till then 15:38:24 @miconda I was referring to the issues that you opened targeting more or less yourself -- eg., related to cfgt, sca, dialplan, ... 15:38:42 @miconda * I was referring to the issues that you opened targeting more or less yourself -- eg.g, related to cfgt, sca, dialplan, ... 15:38:48 @miconda * I was referring to the issues that you opened targeting more or less yourself -- eg., related to cfgt, sca, dialplan, ... 15:39:14 @miconda but again, nothing critical at all, just a soft reminder ... 15:39:50 @miconda they can just stay there ... until we reach the capacity of the tracker ;-) 15:40:22 @miconda next topic then ... 15:40:34 @miconda minor releases -- 15:41:32 @miconda for 5.4, probably sometime next week (2nd part) or the week afterwards would be a good target 15:42:10 @miconda for 5.3, Henning Westerholt plans to take over this series 15:42:33 @miconda if Henning is busy, I can do it after the next in 5.4.x 15:43:05 @henning miconda: i will do it 15:43:06 @miconda 5.3.x needs to be checked and see if there are relevant fixes there 15:43:12 @henning as we discussed 15:43:21 @miconda the last 5.3.x was not that long ago 15:43:50 @henning i was thinking maybe doing either before or after christmas, 5.3 release 15:44:20 @miconda Henning Westerholt: sure, appreciated! just saying because it can happen that you become busy, so others can take over temporarily 15:44:48 @miconda fine with me the plan for 5.3.x 15:45:24 @miconda for Debian we have nightly builds, so that's always good to get fixes quickly 15:45:37 @miconda I do not remember if the new rpm repo does nightly for stable branches 15:45:55 @miconda not sure if sergey is here now to confirm ... 15:46:07 @miconda or maybe someone that uses the rpm repo 15:46:53 @miconda even when I plan to go with repos, I end up quickly switching to sources, usually needing to cherry pick some feature from master ... 15:47:05 @miconda so I haven't paid much attention to packaging 15:47:51 @miconda anything else on minor releases?!? 15:48:16 @miconda if not, then next topic: packaging 15:48:41 @miconda I think Víctor Seva is packaging already `kamcli` 15:48:54 @miconda am I right, Victor? 15:49:03 @vseva kamcli is already in Debian 15:49:16 @vseva https:packages.debian.org/search?keywords=kamcli 15:49:22 @miconda in Debian distro, or Debian repo on kamailio.org? 15:49:30 @miconda ohh, nice, thanks! 15:49:40 @henning is kamcli this a "suggest" for the packages as well? its no dependency 15:50:10 @vseva > \@miconda:matrix.kamailio.dev in Debian distro, or Debian repo on kamailio.org? 15:50:15 @miconda Víctor Seva: is kamcli also on deb.kamailio.org repo? like nightly build? 15:50:22 @miconda :-) 15:50:33 @miconda you read my questions ahead :-) 15:50:42 @vseva :-) 15:51:01 @oej While discussing packaging 15:51:04 @oej can we discuss https:github.com/sipwise/kamailio-deb-jenkins/issues/9 15:51:08 @vseva We discuss to add ubuntu latest version I think 15:51:32 @oej I am a bit worried over old versions being deleted 15:51:51 @vseva well, yes I would like to have aptly instead of reprepro 15:52:08 @miconda the other one I would like to get packaged somehow is libsecsipid ... I have to buy a cerveza for Victor 15:52:14 @vseva but old versions are not removed... they are not in the repo 15:52:26 @oej just on cerveza? 15:52:28 @oej one 15:52:32 @jsmith miconda: I've already been working on an RPM for libsecsipid 15:52:39 @miconda libsecsipid is for the STIR/SHAKEN module, in USA things move forward with it and some carriers deploy it 15:52:52 @vseva now I'm on diet, no alcohol for me :-( 15:53:04 @apogrebennyk Víctor Seva: you? what happened? =) 15:53:13 @apogrebennyk sorry for OT. 15:53:17 @miconda Jared Smith: nice, thanks! you can make a PR with the specs and then @sergey can add it to our rpm building process 15:53:18 @vseva :-) 15:53:33 @vseva apogrebennyk: nice to see you! 15:53:40 @apogrebennyk Víctor Seva: same :) 15:53:42 @jsmith miconda: Will do, once it's done and tested :-) 15:54:30 @vseva > \@miconda:matrix.kamailio.dev the other one I would like to get packaged somehow is libsecsipid ... I have to buy a cerveza for Victor 15:54:37 @miconda libsecsipid requires golang to build, but then no other fancy dependencies 15:54:59 @vseva packaging golang is not fun at all 15:55:12 @vseva * packaging golang is not fun at all 15:55:16 @miconda no need to package golang 15:55:36 @vseva I mean golang programs 15:55:38 @miconda just install golang from debian repo, to build libsecsipid.a and libsecsipid.so, and that's it 15:56:02 @miconda it doesn't create package dependency 15:56:17 @miconda so installing libsecsipid from deb won't require to install golang 15:56:18 @vseva no external dependences? 15:56:29 @miconda golang is only build dependency 15:56:39 @vseva then it's easier 15:56:43 @miconda no, everything is bundled in a file 15:56:51 @miconda it is golang, not Node.js :-) 15:57:10 @miconda * it is golang, not Node.js :-) 15:57:10 @vseva well is about dependences to build 15:57:45 @vseva but if we don't have any... I will try to take a look 15:58:28 @miconda you only need golang package (the compiler), afaik 15:58:48 @miconda haven't done it recently, because I installed it long time ago and now just doing usual updates 15:58:59 @miconda but it was easy 15:59:08 @miconda some environment variables need to be set 15:59:26 @miconda we can discuss between us when you have some time and I can give hints 16:00:01 @matt44w and now with go.mod it is easier 16:00:34 @miconda didn't get to use complex stuff like go.mod :-) 16:00:48 @vseva I have some experience with golang due to cgrates 16:01:04 @miconda libsecsipid uses only an external package to generate UUID, which go gets it automatically 16:01:42 @vseva then you have an external dependence!! 🤣 16:01:58 @henning lol 16:02:04 @vseva build on debian is done without network 16:02:26 @vseva all dependencies had to be packaged 16:03:08 @miconda ok, then we need to look into it 16:03:21 @miconda we will do it when we have some time 16:04:01 @miconda next topic related to packaging was @oej already pointed above 16:04:12 @miconda keeping old versions 16:04:18 @miconda and Víctor Seva replied 16:04:33 @miconda not sure if anything else needs to be added 16:05:04 @miconda iirc, from last devel meeting in Dusseldorf, the rpm repo should keep many versions 16:05:36 @miconda sergey seems to be offline, so cannot confirm 16:05:48 @henning the rpm one has old versions 16:05:55 @henning * the rpm has old versions 16:06:02 @henning * the rpm one has old versions 16:07:02 @vseva any problems with travis-ci do we need to move to github actions? 16:08:40 @miconda I have no experience with github actions 16:09:02 @miconda if they are considered better and if someone wants to switch to, I am fine 16:09:49 @miconda I think with travis-ci sometimes the notifications on failed builds are not coming to mailing list 16:09:57 @oej Is there a reason to leave Travis-ci? 16:10:08 @miconda haven't really watched closely, but somehow I got that feeling over the time 16:10:27 @miconda but no other complain from my side 16:10:34 @henning we might want to not move anything to github 16:10:42 @miconda and again, it may not be even true 16:10:59 @vseva https: 16:11:45 @vseva everything related to travis-ci is related to tests so not essential 16:12:11 @vseva > \@henning:matrix.kamailio.dev we might want to not move anything to github 16:13:18 @mojtaba 8;] 16:13:20 @miconda Víctor Seva: so they (travis-ci) are going to discontinue the free service for open source by end of year? or I didn't get right that blog post on a quick read? 16:13:37 @henning had not heard from it as well before 16:14:09 @miconda in the blog post: December 31, 2020: Travis-ci.org will be put into read-only mode. 16:14:26 @miconda so maybe existing repos still go on, but if so, likely not for long time 16:15:31 @vseva https:blog.travis-ci.com/2020-11-02-travis-ci-new-billing 16:16:27 @vseva > We will be offering an allotment of OSS minutes that will be reviewed and allocated on a case by case basis. Should you want to apply for these credits please open a request with Travis CI support stating that you’d like to be considered for the OSS allotment. 16:16:51 @henning \great 16:17:16 @miconda ok, so we may have to look at github actions ... 16:17:18 @miconda soon 16:17:38 @oej Maybe ask for "OSS minutes" while preparing the move 16:18:59 @miconda travis-ci made me a bit lazier over the time, pushing small changes without compiling, then waiting for notification of failed to build, ... :-) 16:19:16 @miconda now have to work more again ... 16:19:28 @miconda :-) 16:20:35 @jchavanton 1000 minutes, the CI seems great in terms of coverage but is taking a long time to run 16:21:03 @jchavanton Does it mean we need to use the WIP tag (to skip CI) until we are sure 16:21:05 @miconda so 1000min means compiling the first 10 modules :-) 16:21:50 @miconda ok, we will see what happens and what we can do ... 16:22:18 @miconda ultimately we can use some docker to do builds on out server for a few distros 16:22:48 @miconda if nothing to be added, we can move to next topic 16:23:13 @miconda - administration - 16:23:30 @miconda this is just rolling over in every agenda 16:23:55 @miconda kamailio.org runs last debian stable, so nothing important to be done soon for it 16:24:24 @miconda the usual kernel updates from time to time, with very short downtime 16:25:07 @miconda then I think we are doing fine with mailing lists, this matrix group and the old irc ... 16:25:29 @miconda but you can always propose new (online/offline) tools to use 16:25:46 @henning the day to day maintenance of is going fine, i usually do it once a week for some minutes 16:26:08 @henning we have some time left until the next debian upgrade is necessary ;) 16:26:50 @miconda ok -- seems all good on this one 16:27:07 @miconda next topic 16:27:14 @miconda next major release 16:28:00 @miconda in terms of timing, likely end of spring, as I can see it now 16:28:10 @miconda or at least 2nd part spring 2021 16:28:26 @miconda quite a bunch of new features in existing components 16:28:41 @henning you pushed some modules today 16:28:45 @henning great work at 16:28:54 @henning thank you 16:28:54 @miconda 1 module 16:29:22 @miconda which is going towards what we discussed for Kamailio 6.0 in Dusseldorf last year 16:29:46 @jchavanton > \@miconda:matrix.kamailio.dev 1 module 16:29:53 @miconda having a group of processes that can handle the SIP traffic, no matter what is the transport they come in 16:30:09 @miconda but is a hybrid solution for now 16:30:25 @joelsdc1 > \@miconda:matrix.kamailio.dev ok, so we may have to look at github actions ... 16:30:27 @miconda obviously, still WIP, today only the skeleton 16:31:03 @miconda the current design should work for UDP, likely for TCP, hoping for TLS ;-) 16:31:18 @henning @miconda about the work distribution topic, do you think a module might be ultimately the way to go forward, or we might need to extend the core in this regards 16:31:44 @miconda it still needs the usual SIP receive workers, but only to read from sockets, then push in internal queues 16:32:14 @miconda Joel Serrano: you are more than welcome to join and help with GH actions 16:32:39 @miconda Henning Westerholt: the module is just a wrapper to the core framework, for config functions 16:33:47 @miconda so right now is like: request received as usual by a sip worker, and then passed to a group of "independent" workers, using in memory sockets for immediate reaction 16:34:08 @miconda and from there goes again to request_route for usual processing 16:34:33 @miconda but I will have to a sort of pre-routing event route to decide this kind of delegation for processing 16:35:00 @miconda to avoid executing twice some internal callback for pre/post-config processing 16:35:24 @miconda I will send more details when it gets to a better shape 16:36:42 @miconda it reuses the code from core related to async task processing, but no longer creates and suspends the transaction ... passes the request as it is received and the sip receiver can read the next one, then it can pass to another group 16:37:25 @miconda this is the first stage not to be very intrusive and change radically exiting design, to avoid the need to change code in modules 16:38:17 @miconda iirc, Federico Cabiddu started the topic in Dusseldorf last year 16:38:44 @miconda we planned to do some coding this year, but obviously some virus didn't want us meet again this autum :-) 16:39:51 @federico sounds very good :) 16:39:55 @miconda the version from today lacks ability to define groups of worker processes, to be added next 16:40:02 @oej Sounds cool 16:40:50 @miconda expect more details on mailing list next week, or so 16:41:06 @miconda I wanted to show today that work started :-) 16:41:30 @henning great 16:41:59 @miconda then, before presenting what other modules I consider for next release, let's hear about LREPRoxy 16:42:21 @miconda mojtaba.esfandiari wanted to discuss its status and his plans here 16:42:38 @mojtaba.esfandiari Yes, Sure 16:44:13 @mojtaba.esfandiari LREProxy is powerful and useful module that is developed for Kamailio for relaying RTP session in high performance 16:45:34 @miconda is it based on the existing pull request, or you wrote it from scratch again? 16:46:02 @oej Please explain why you wrote yet another RTP module in addition to the ones we have :-) 16:46:10 @mojtaba.esfandiari You could run LREProxy module in a simple computer server. It could handle and relaying RTP between peers more than other modules in Kamailio as well as connection tracking in Linux 16:47:58 @oej Maybe I'm stupid, but don't we already have integration with iptables in kernel in some modules? 16:48:45 @miconda oej rtpengine app does that 16:48:59 @mojtaba.esfandiari The concept of developing this module is because of in SBC node or edge-node in network we have huge number of incoming real-time packet 16:49:14 @oej @moj 16:49:23 @miconda there was long time ago another module in kamailio using kernel, but removed, required a non-maintained patch to kernel 16:49:41 @mojtaba.esfandiari And it could consume more resources in server. 16:49:55 @oej So the existing modules/apps failed for you? 16:50:20 @mojtaba.esfandiari With using LREProxy, you could handle more RTP serssion relaying with no more consuming resources 16:50:55 @mojtaba.esfandiari RTPEnging app dose the same work but in local-hooking network stack 16:51:21 @mojtaba.esfandiari LREProxy do this in prerouting-hooking in netfilter 16:51:59 @mojtaba.esfandiari oej: absolutely yes 16:52:29 @mojtaba.esfandiari For more information about this:https: 16:52:51 @henning i think the focus of rtpengine is more to provide a wide range of RTP handling functionality, and the focus of lreproxy more on proxy performance and throughput, correct? 16:52:52 @mojtaba.esfandiari This module also accepted in ICCKE2020 conferences, too 16:53:27 @mojtaba.esfandiari I think during next week this module could be published in Kamailio project 16:53:43 @miconda mojtaba.esfandiari so we wait for you pull request and then see how people find it good to use 16:55:02 @mojtaba.esfandiari Henning Westerholt: Yes, For edge nodes that encountered with huge number of packets per second 16:55:37 @mojtaba.esfandiari miconda: Sure, During next week 16:56:21 @oej Why the name "LRE"? Seems confusing. 16:56:33 @mojtaba.esfandiari Already, the LREProxy engine have developed with Python, it will publish, too. 16:58:03 @jchavanton > \@oej:matrix.kamailio.dev Why the name "LRE"? Seems confusing. 16:58:06 @miconda ok, then we wait for next week and can discuss on GH PR if is more to say 16:58:16 @mojtaba.esfandiari oej: The LRE means Light-RTP-Engine, becuase the logic of the module uses off-loading Cpu techniques. 16:58:45 @miconda since Julien Chavanton is active and he did a lot of code lately 16:58:59 @jchavanton > \@mojtaba.esfandiari:matrix.org oej: The LRE means Light-RTP-Engine, becuase the logic of the module uses off-loading Cpu techniques. 16:59:01 @miconda anything else new coming from you soon, Julien? 16:59:11 @oej "RTP-engine" is a product name, so I would consider avoiding that 16:59:12 @jchavanton I saw Salman Ali @asalman18 was present, he helped with the review of dispatcher algorithm 13. 16:59:42 @henning oej: we can discuss on the name as well on the patch/pull request then 17:00:16 @mojtaba.esfandiari Sure, No problem. It is just name and could be changed :) 17:00:35 @miconda Julien Chavanton isn't algo 13 already merged? 17:01:49 @mojtaba.esfandiari Any question? 17:02:52 @mojtaba.esfandiari maryambaghdadi: Mariam help me in developing Kernel-Space section in LREProxy. 17:03:16 @jchavanton > \@mojtaba.esfandiari:matrix.org Any question? 17:03:52 @mojtaba.esfandiari Mariam do you want to say somethings about our work in lreproxy? 17:04:45 @jchavanton > \@miconda:matrix.kamailio.dev Julien Chavanton isn't algo 13 already merged? 17:05:02 @miconda so we can move to next topic 17:05:31 @miconda anyone else that wants to share what they plan to add till 5.5 is out? 17:06:12 @jchavanton There may be an improvement to RTPengine module, I am waiting for a review on RTPengine before I submit the module part 17:06:13 @miconda from my side: maybe some additions related to JWT 17:06:45 @miconda and want to look at the RFC related to push notifications, although I hoped Federico Cabiddu is going to be faster than me ;-) 17:06:56 @oej On my wishlist: Support for the new SHA* auth in combination with MD5 according to the RFC 17:07:05 @oej But that's a feature request 17:07:19 @miconda Julien Chavanton ok 17:07:19 @oej if I get time I will make ds_list_exists support pvars 17:07:47 @miconda isn't ds_list_exists() supporting vars? 17:08:46 @henning i have some changes that i like to merge: one addition to the crypto module, another operating mode to support interoperability with other implementation for crypt/decrypt, and some additions to topology hiding for more flexibility in contact header handling 17:09:12 @miconda code suggests ds_list_exists() does support var as parameter, like ds_list_exists("$var(id)") 17:11:44 @miconda ok, if nothing to be added here, we can go to next topic 17:12:00 @oej > \@miconda:matrix.kamailio.dev code suggests ds_list_exists() does support var as parameter, like ds_list_exists("$var(id)") 17:12:20 @miconda I assume everyone is ok with the loose plan of 2nd part/late spring 2021 for target date of 5.5 release 17:13:58 @henning fine with me 17:14:23 @fred works for me 17:14:34 @miconda ok 17:14:44 @miconda so then the wiki/documentation 17:15:12 @henning for development docs i think Markus Böhnke did some conversion scripts some months ago 17:15:35 @miconda Julien Chavanton - you mentioned something above 17:15:44 @miconda can you elaborate more ... 17:18:06 @jchavanton I would like to write an article on how-to use algorithm 13 it may not be that intuitive, I do not want to put to much details about one algorithm in the html doc, while trying to explain it in the mailing list it was clear that a wiki page would result in better content. 17:18:37 @oej We can publish something on the home page to start page 17:18:45 @oej s/start/web page/ 17:19:17 @oej sorry multitasking 17:19:33 @oej An article like that could be published to introduce the algo 17:19:58 @fred Yeah... would be good as a post 17:20:24 @miconda Julien Chavanton - there is a repo on github for docs, maybe you can add it there 17:20:50 @miconda https:github.com/kamailio/kamailio-docs 17:21:02 @miconda * Julien Chavanton - there is a repo on github for docs, maybe you can add it there 17:21:06 @jchavanton > \@miconda:matrix.kamailio.dev Julien Chavanton - there is a repo on github for docs, maybe you can add it there 17:22:17 @miconda yes, we will do also a news about, but I thought you want to have something to improve and maintain over the time 17:23:10 @miconda Henning Westerholt - if you have reference to what Markus did, try to paste here a link to work from there 17:24:15 @henning ok, i will need to dig out the message 17:24:15 @miconda but the main question is: shall we migrate dokuwiki to markdown (e.g., mkdocks, ...) and use github repo to accept content with PRs? 17:24:17 @henning but will do 17:24:29 @miconda * but the main question is: shall we migrate dokuwiki to markdown (e.g., mkdocks, ...) and use github repo to accept content with PRs? 17:26:06 @miconda silence is an answer, too :-) 17:26:22 @miconda * silence is an answer, too :-) 17:26:42 @fred I like the idea of markdown 17:27:29 @federico I like the idea of managing the doc too through PRs 17:28:21 @miconda ok, so let's try to do it 17:28:51 @miconda we can still have it shown on kamailio.org, just stored on github 17:29:10 @miconda for the benefit of PRs 17:29:25 @miconda so people do not need to make an account on our dokuwiki portal 17:29:59 @miconda I looked at the option of using git backend for dokuwiki, but didn't seem that easy at that moment and then also the format is different than the usual markdown 17:30:19 @miconda so if we do it, then better switch both 17:30:35 @miconda then people that contribute can use the markdown format 17:31:27 @miconda ohhh ... a really good session so far, almost 2h30min ... 17:32:00 @miconda let's try to get slowly to the end ... 17:32:19 @fred =) 17:32:32 @miconda last main topic ... community: collaboration, announcements 17:32:48 @miconda anything that someone wants to work on and would like others to join? 17:33:16 @miconda anything that you want to announce (in what cool cases have you used kamailio lately ;-) )? 17:33:27 @miconda or new products, tools, ... etc. 17:33:39 @jsmith You already mentioned secsipid, but I'll continue to test and make suggestions/PRs on that 17:34:13 @miconda Jared Smith - really appreciating that, STIR/SHAKEN is not much in Europe 17:34:27 @miconda so not easy to test in "production-like" interconnects 17:34:54 @fred Recently switched APIBAN to redis backend for some parts... and I was thinking of stupid uses, and thought maybe htable could be used (with http front end). It couldn't, but just for fun, was able to run over 1000cps on a pi 17:35:22 @fred so htable would store json, and return it via xhttp 17:35:29 @fred * so htable would store json, and return it via xhttp 17:35:34 @jsmith Fred Posner: Have you checked out the KeyDB fork of Redis? Much higher performance, and multi-master :-) 17:35:59 @fred No, only because it hasn't reached any concern of that level yet 17:36:06 @miconda not sure if Torrey Searle is online now, but he added some mocking stuff for KEMI Python, so if anyone uses that, check it: https:github.com/kamailio/kamailio/tree/master/misc/tools/kemi/python_mock 17:36:47 @miconda * not sure if Torrey Searle is online now, but he added some mocking stuff for KEMI Python, so if anyone uses that, check it: https:github.com/kamailio/kamailio/tree/master/misc/tools/kemi/python_mock 17:37:35 @miconda then, for KEMI Lua, I added some tools that can help detecting errors in the Lua script: https:github.com/kamailio/kamailio/tree/master/misc/tools/kemi/lua 17:40:14 @miconda and again from me - the URL expander extension for browser to jump quickly to kamailio web resources - already announced to mailing list, but for the records: https:github.com/miconda/KSR-URL-Expander 17:43:46 @miconda last call if someone still wants to add something here 17:44:09 @miconda if not, we can consider this meeting finished! 17:44:35 @miconda thanks everyone for participating! 17:44:48 @miconda now free discussions ...