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:www.kamailio.org/wiki/devel/irc-meetings/2020b
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:www.jeffgeerling.com/blog/2020/travis-cis-new-pricing-plan-threw-wrench-my-open-source-works
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 www.kamailio.org 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:www.slideshare.net/mespio/lreproxy-module-for-kamailio-presenation
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 ...