Kamailio SIP Server Wiki

User Tools

Site Tools

Trace: • 2020b

Sidebar

devel:irc-meetings:2020b

Table of Contents

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 :wave:
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 <ironic>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 …

devel/irc-meetings/2020b.txt · Last modified: 2020/11/25 21:55 by qxork

Page Tools

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki