Kamailio SIP Server Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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:**
  * Matrix chat room: **#kamailio:matrix.kamailio.dev**
    * https://riot.kamailio.dev/#/room/#kamailio:matrix.kamailio.dev
  * To join as a guest:
    * go to: https://riot.kamailio.dev/#/welcome
    * click on **Room Directory**
    * then click on **kamailio** room to join it 

//Backup place://
  * IRC channel: **#kamailio** on **irc.freenode.net** server


Utilities:
  * [[http://www.timeanddate.com/worldclock/converter.html|Time Converter]]
  * Matrix resources
    * website: https://matrix.org/
      * it allows public registrations for getting a Matrix user account
    * client applications: https://matrix.org/clients
    * unofficial list of other public matrix servers: https://www.anchel.nl/matrix-publiclist/
  * IRC resources
    * IRC webchat: http://webchat.freenode.net/
    * IRC client apps: http://en.wikipedia.org/wiki/Internet_Relay_Chat#Clients

===== 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:

  * open issues (dcm)
  * minor releases for 5.3 and 5.4 branches (dcm)
  * tracker issues review, e.g.,:
    * https://github.com/kamailio/kamailio/issues/969
  * packaging: secsipid, kamcli
  * debs repo with many versions

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 ...\\
Kamailio SIP Server Wiki

User Tools

Site Tools

Page Tools
