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.
====== IRC Devel Meeting - 2018-06-26 ======

Date:
  * **Proposed: 14:00 UTC, Tuesday, Jun 26, 2018**
    * can attend: dcm vseva qxork jchavanton cchance henningw
    * cannot attend:
  * Alternatives (add your id if you can attend)
    * Jun 27: dcm qxork cchance 

Time of the meeting across the world:
  * 16:00 - Berlin, Germany
  * 15:00 - London, UK
  * 10:00 - New York, USA
  * 07:00 - Seattle, USA

Utilities:
  * [[http://www.timeanddate.com/worldclock/converter.html|Time Converter]]
  * IRC webchat: http://webchat.freenode.net/
  * IRC client apps: http://en.wikipedia.org/wiki/Internet_Relay_Chat#Clients

Place:
  * **#kamailio** IRC channel on **irc.freenode.net** server

===== 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
  * qxork - Fred Posner
  * mwolff - Mathias WOLFF

===== Agenda =====

Kamailio Development Status:

  * open issues (dcm)
  * minor releases for 5.0 and 5.1 branches (dcm)

Administration:

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

Kamailio 5.2 (next major release):

  * roadmap
  * features
    * anything relevant that is missing?
    * priorities

Documentation:

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

Collaborative Projects:

  * unit testing, documentation, etc.

===== Transcript of Meeting =====

Note: Times are in EDT (UTC -4)

<code>
[10:02am] miconda: ok, I guess we can start ...
[10:02am] miconda: the wiki page, in case anyone wants to add content there: https://www.kamailio.org/wiki/devel/irc-meetings/2018a
[10:03am] miconda: first topic: open issues
[10:04am] miconda: anyone facing some unaddressed issue that it is causing big troubles?
[10:04am] qxork: Nope
[10:04am] cchance: None here
[10:04am] miconda: somehow related, minor releases -- we had 5.0.7 recently and 5.1.4 a bit before
[10:05am] miconda: likely the 5.1.5 to be in a few weeks
[10:05am] miconda: ok, all good then
[10:06am] miconda: probably we can go no to the next major release
[10:06am] miconda: and then to admin stuff
[10:06am] miconda: so we released 5.1.0 in December last year
[10:07am] miconda: so 5.2.0 should be out in autumn more or less
[10:07am] miconda: there are couple of new modules already in the master branch
[10:07am] miconda: I did quite a bit of a work for dispatcher in the past few weeks
[10:07am] miconda: I have to write a blog post for it to make it easy for people to migrate and understand the new features
[10:08am] miconda: anyhow, the question would be: anything major that we should focus on to get in 5.2.0?
[10:08am] henningw: hello - I will focus a bit more on some core parts, a bit security related, a bit general re-factoring and improvements
[10:08am] henningw: but autum should be fine for me in this regards as well
[10:09am] henningw: fixes can also be applied in freezing period, of course
[10:09am] miconda: in my list, if I get the time, is to look a bit deeper at the dialog module and eventually refactor its internal id -- now it's a pair of two numbers, but they can easily overlap on distributed nodes
[10:09am] cchance: I have some DMQ improvements/enhancements to merge into master - nothing major so will be ready easily by then
[10:10am] miconda: dialog itself won't be a big issue, but there are couple of other modules relying on it: presence dialoginfo, cnxcc, ...
[10:11am] eschmidbauer: cchance: dmq/presentity record stuff?
[10:11am] miconda: another thing that I may do for dialog is to remove the dependency on transaction for dialog states, and only use tm for sending requests (like keepalive or byes)
[10:12am] henningw_: if the transaction state is not needed in dialog, this would be indeed a good idea
[10:13am] miconda: ahh, and since we are here, I just want to open the topic with the version table for database ... I am going to write a proper email to the lists, but I thought of adding something like a minimum compatibility version
[10:13am] cchance: eschmidbauer: no, core dmq stuff mainly - removing dead nodes from bus, grouping nodes together into logical roles/interests
[10:13am] eschmidbauer: nice
[10:14am] miconda: the idea is to make it a bit more friendly during upgrades
[10:14am] mwolff: hi
[10:14am] henningw_: minimal version - this would also mean to add some kind of compatibility layer in the respective modules, if I understood it correctly?
[10:14am] cchance: miconda: +1 to minimum compatibility
[10:15am] miconda: for example, when adding a new column in a newer release, upgrading from old version would require adding the column and increasing the version number. However, if something goes wrong, running previous version would just work fine without dicreasing the version number
[10:15am] henningw_: ah, I see
[10:15am] henningw_: agreeing that this is of course a pain especially for not experienced users
[10:15am] qxork: sounds like a good idea
[10:16am] miconda: so it can make it a bit more convenient
[10:16am] miconda: of course, if there are majore changes in the structure of the database/table, then we can set min required to the current version
[10:17am] henningw_: understand  - I could help here a bit with the database infrastructure as well
[10:17am] miconda: also just to note it here: some of modules behave differently based on version number, for example dispatcher...
[10:17am] miconda: henningw_: thanks, that would be appreciated
[10:18am] miconda: another thing that might be good to add is to be able to disable completely the db version check
[10:19am] miconda: I added to couple of modules, because I got into some situations when the deployment environment didn't allow creating new tables and I had to connect to some other databases
[10:19am] cchance: interesting, could be useful, maybe for more experienced users
[10:19am] henningw_: +1
[10:19am] miconda: like for auth_db, connecting to asterisk realtime database to take the 'secret' from there
[10:19am] henningw_: for not experienced user it would be probably not good to disable it by default
[10:20am] miconda: auth_db allows full flexibility with column names, table name ...
[10:20am] henningw_: also for supporting on sr-users and this things
[10:20am] miconda: yes, disabled by default
[10:20am] miconda: anyhow, we can discuss and tune implementation details via mailing lists
[10:21am] miconda: some other ideas that are "nice to have" in 5.2?
[10:21am] miconda: maybe some of us get bored during this summer ;-) ?
[10:22am] henningw_: i have one thing related to core - currently the str type is using a unsigned int as length, and this is not optimal from a security POV. But changing this would be a big intrusive change, needs to be discussed more on sr-dev.
[10:22am] henningw_: sorry, its a signed (normal) int
[10:22am] miconda: yes, signed int
[10:22am] henningw_: with is of course bad if its overflow to negative
[10:22am] miconda: you want uint32_t?
[10:22am] henningw_: unsigned, yes
[10:23am] henningw_: i will do some simple test to see how intrusive this change would be
[10:23am] miconda: needs to be analyzed, it might be some cases when len is set to -1 as a marker for some uninitialized cases ...
[10:23am] henningw_: and if it makes sense comparing to the benefit
[10:23am] miconda: ok
[10:24am] Elhodred: I've the MR for the str hash tables in shm, I agree with what we discussed in the mailing list that I should separate it
[10:24am] miconda: I do not have any strong reason against
[10:24am] henningw_: Elhodred - yes, we should just add a dedicated .h and implementation file
[10:25am] miconda: Elhodred: yes
[10:25am] Elhodred: I've it almost ready, how do you want to proceed regarding the MR? shall I close the current one and create a new one or should I just force an update to my branch and that's all?
[10:25am] miconda: walking through the code might reveal other parts that can be reused, or made as a generic api to be reused
[10:26am] miconda: Elhodred: I think a new PR is better
[10:26am] Elhodred: ok
[10:27am] miconda: anything else in terms of new features?
[10:27am] miconda: otherwise, in terms of timelines to the next major release
[10:28am] miconda: maybe freezing development by mid of September, to allow some of us to have holidays and then a bit of a time frame to code before
[10:28am] miconda: then testing and releasing during the second part of October or first part of November
[10:29am] miconda: a matter of how well the testing goes
[10:29am] henningw: sounds good for me
[10:29am] miconda: ok
[10:31am] miconda: then let's go into testing framework - functional/unit testing (there were some discussions on how to name it during kamailio world)
[10:31am] cchance: Sounds good. Just quickly on new features, I would welcome requests/ideas for other modules which would benefit from DMQ integration ;)
[10:31am] miconda: cchance: ok, I will upload a file to Dropbox, the list is too large to email it ;-)
[10:31am] cchance: :D
[10:31am] qxork: cchance: does dialog already integrate?
[10:32am] cchance: Yep
[10:32am] cchance: I have shared secret working for auth module too
[10:32am] miconda: cchance: nice one
[10:33am] qxork: cchance: awesome
[10:33am] cchance: Anyway, sorry for the interruption
[10:33am] miconda: no worries, back to testing framework then
[10:34am] miconda: any ideas of what can be done to make it more popular
[10:34am] miconda: or eventually ideas of make it better
[10:35am] miconda: I think we should at least migrate the old units from henningw's work
[10:35am] miconda: likely it needs to take one by one, although both use shell scripts, still some changes needed
[10:36am] miconda: but then we can remove the test/unit folder from kamailio git repository
[10:37am] cchance: I'm not familiar enough with it to comment, although we're doing lots with Docker/Swarm atm and intend to make use of it soon. I'm sure we'll have some input then.
[10:37am] miconda: ok ... we can also try to address this topic on mailing lists
[10:38am] henningw: the test topic would be a good work for somebody which is new to kamailio
[10:38am] miconda: for the records, more details about the proposed framework at: https://github.com/kamailio/kamailio-tests
[10:38am] henningw: if there are any questions to the old one, I am happy to answer them
[10:39am] henningw: the new ideas are described in the links miconda just posted
[10:39am] miconda: let's then move on documentation
[10:40am] miconda: one big I have in my agenda is trying to find a way to reference native config docs with kemi exports
[10:40am] miconda: mainly in respect to module functions
[10:41am] miconda: then another one that I want to address here is the wiki
[10:41am] henningw: native, e.g. mod READMEs?
[10:42am] miconda: henningw: reference a kemi function to the docs of the native cfg function documented in the readme of the module
[10:42am] miconda: or in other words, a way to reuse the documentation for the functions that do the same thing
[10:43am] miconda: not to duplicate efforts to document a function twice, once for native cfg and one more time for kemi export
[10:43am] henningw: ok, understood. at the moment the READMEs are individual documents. If they all would be in one doc namespace, this would be simple - just refer to the ID
[10:43am] henningw: just thinking
[10:43am] miconda: in some cases there are several kemi exports for the same native cfg function
[10:43am] henningw: not duplicating this docs would be great
[10:44am] miconda: and a rahter major diference with the return code evaluation, as native cfg evaluate negative to false and positive to true and 0 to exit
[10:45am] miconda: we will see what comes up after some brainstorming ...
[10:45am] miconda: so the other one was the wiki
[10:46am] miconda: one thing I thought of was to allow authentication using IDs from external services, like github
[10:46am] miconda: so we do not have to ask people create accounts on the wiki, as this mainly allows spammers to create accounts
[10:46am] qxork: github makes sense since we host on github
[10:47am] qxork: github and twitter would both make sense to me
[10:47am] henningw: github sounds good
[10:47am] cchance: +1
[10:47am] miconda: as I am looking at the new accounts, the majority are spammers
[10:47am] henningw: we had this issue with the captcha
[10:47am] henningw: so getting rid of this captcha would  be also good
[10:47am] cchance: is it a straightforward change?
[10:47am] miconda: the alternative is to host the files on github and fetch them on kamailio server only for display
[10:48am] miconda: so editing goes like it is done with the code more or less, either via direct commit by devs and pull requests by others
[10:48am] cchance: hmm, that actually sounds better
[10:48am] henningw: for us it would be probably easier, but for the causal user?
[10:48am] cchance: we do that ourselves and it works really well, even for non-developers
[10:48am] cchance: (using GitLab, at least)
[10:48am] henningw: ok, interesting
[10:49am] cchance: not used GitHub web UI for making edits but assume it's identical
[10:49am] henningw: what about giving github as login ID a try, and if everything works out great, proceed with the next step also changing hosting?
[10:49am] henningw: changing edit work-flow
[10:49am] miconda: I did it couple of times, it's fine to edit via web ui with github
[10:50am] henningw: good point
[10:50am] miconda: henningw: the thing is that there were not many contributions to the wiki lately
[10:50am] henningw: you're right - it did not helped as the registration was broken for some time as well :-(
[10:50am] miconda: so apart of developers adding new content as they coded stuff, not many contributing to enhance the content
[10:50am] qxork: As I think on it, it seems like moving it to guthub would make it more open for contribution. My concern is relying too much on github.
[10:51am] miconda: I don't think the registration not working was the real issue, the first that discovered and wanted to add something, just reported it
[10:51am] miconda: qxork: right, microsoft ;-)
[10:52am] miconda: but then is practically git
[10:52am] miconda: we can have a clone on out servers
[10:52am] cchance: Easy enough to migrate to gitlab later if necessary
[10:52am] qxork: or gogs ;)
[10:52am] miconda: the system behind it should work the same (I mean here the tools to fetch content on kamailio.org for displaying, etc...)
[10:52am] henningw: we need to observe the situation regarding github, and then decide to migrate if necessary
[10:53am] henningw: at the moment I don't see a need to migrate
[10:53am] miconda: henningw: agree
[10:53am] cchance: miconda: mkdocs works well in that respect
[10:53am] mwolff: agree
[10:54am] miconda: cchance: yes, mkdocs could be an option
[10:54am] miconda: I migrated some of the wiki pages to mkdocs
[10:55am] miconda: we need to work on some tools to automate it a bit -- fetching from github and publishing on kamailio.org
[10:56am] miconda: probably the alphabetic indexes can be easily generated in markdown
[10:56am] miconda: I can look at that, its mainly xsl extracting from xml module docs
[10:57am] miconda: so if someone does it already and can share some scripts, we can try to reuse
[10:58am] miconda: I guess we can go to next topic
[10:58am] miconda: infrastructure administration
[10:58am] miconda: I think kamailio.org is still with old debian
[10:59am] miconda: soon we need to plan a maintenance window to upgrade it
[10:59am] miconda: thanks to voztele, we got more cpu, memory and hdd
[10:59am] henningw: this helped a lot!
[10:59am] henningw: the server is pretty fine now again regarding performance
[11:00am] qxork: On those lines, I should upgrade the lod kamailio servers to stretch as well
[11:00am] henningw: about an update - I think one option would be to migrate the development stuff and some secondary services to a new system
[11:01am] qxork: henningw: I think the new one is already stretch
[11:01am] miconda: so here ... are people using some apps/frameworks/... that you think kamailio project would benefit from running them ...
[11:01am] qxork: most of my sites are nginx with wordpress or nginx with straight html
[11:01am] miconda: we have couple of spare systems, thanks to qxork
[11:02am] henningw: ok, this is great and would help a lot in migrating and upgrading
[11:02am] henningw: www.kamailio.org should probably stay at the voztelecom infrastructure
[11:03am] miconda: yes, moving from there will require lot of work
[11:03am] miconda: so unless there is a major necessity for it, we are fine with the current setup
[11:03am] henningw: its a plain apache with wordpress and mailman, which works ok so far, no big issues
[11:04am] henningw: For an upgrade a possible timeframe would be in august or september
[11:04am] miconda: ok, we can discuss and sync via kadmin or public lists
[11:05am] henningw: but we have no time pressure - the server is OS wise patched etc..
[11:05am] qxork: ack
[11:05am] henningw: miconda: ok, lets do this
[11:06am] miconda: any collaboration tools that people would like to use?
[11:06am] miconda: are the mailing lists still enough, and the irc?
[11:06am] qxork: I did like the idea of matrix
[11:07am] miconda: meaning the community collaboration
[11:07am] qxork: and/or getting with someone for a weekly “open question” conference call
[11:07am] miconda: qxork: self hosted?
[11:08am] qxork: miconda: yes, we could give another box for it.
[11:08am] miconda: qxork: each box has to come with an human admin
[11:08am] miconda: :-)
[11:08am] qxork: I’d offer to do so
[11:09am] miconda: ok, we can discuss further on mailing lists and get feedback about who wants to be involved in coordinating such sessions
[11:10am] miconda: anything else admin wise that should be addressed/discussed?
[11:11am] henningw: you had the point mailling list review, was this the last point regarding matrix etc..?
[11:11am] henningw: point on the agenda
[11:12am] miconda: henningw: these are more or less generic points I put on agenda of all irc meetings
[11:12am] miconda: but actually it is about the other mailing lists that we are supposed to operate
[11:12am] miconda: like announce and docs
[11:13am] henningw: ok, thanks - I see
[11:13am] miconda: which are kind of not really used
[11:13am] cchance: nothing here, unless there is anything that needs doing and nobody yet has volunteered?
[11:13am] henningw: announce is not really used since some time ago, indeed
[11:13am] henningw: we use business more or less for this purpose
[11:13am] henningw: business list
[11:14am] henningw: and in sr-docs - there were a few mails in the last years, but not that much as well
[11:14am] miconda: henningw: announce was suppose to be used for official announcements from the project, like security issues, major releases, ...
[11:14am] miconda: sr-docs for discussions on how to improve the docs, collaborate on writing docs, ...
[11:15am] henningw: https://www.kamailio.org/w/mailing-lists/
[11:15am] henningw: miconda: yes
[11:15am] miconda: cchance: thanks for volunteering, if something pops up, we will ping you
[11:15am] miconda: qxork: did some bits with announce from time to time, ...
[11:16am] qxork: I’ve dropped the ball on announcements and honestly, had forgotten
[11:16am] cchance: np :+1: [11:16am] miconda: in terms of packaging, I think we are ok now, rpms got good specs, we build them on open suse build service, which is ok form my point of view
[11:16am] qxork: going to make reminders and ensure that doesn’t happen again
[11:17am] henningw: qxork: if you send me a quick reminder I can have a look about subscription stats
[11:17am] miconda: Sergey Safarov did very good work for rpms
[11:17am] henningw: qxork: at announce
[11:18am] miconda: not sure how many people are using *BSD, our specs are way too old, that maybe we should remove
[11:18am] qxork: henningw: ack
[11:18am] miconda: I think freebsd has an official port, maybe I should look at it and see if there are some patches that we can/need to import
[11:18am] linuxmaniac: miconda: remove them, if anyone complains...
[11:19am] henningw: miconda: yes, I remember an email about that as well. there is also a request on github regarding gentoo ebuild
[11:19am] henningw: miconda: that this can be removed
[11:19am] henningw: linuxmanic: we can do this, maybe send a call for interest/help e-mail to the list first :)
[11:20am] henningw: but indeed the specs are really old
[11:20am] linuxmaniac: I see no problem removing them
[11:20am] linuxmaniac: we don't do anything with them
[11:21am] henningw: they are a bunch of packaging file which were contributed from some users, but if they are really outdated and would not work probably anyway, yes they should be removed
[11:22am] miconda: ok, we can remove them
[11:22am] miconda: I was thinking that maybe someone would pick them up and update, but they are sooo old now, that makes no sense to use them
[11:23am] miconda: release procedures and policies -- still ok for everyone?
[11:23am] henningw: we can send a mail to sr-users, if maybe somebody is interesting in looking to the freebsd port and contributing something
[11:23am] miconda: we maintain last two major releases ... so each gets like 2 years  of proper maintenance
[11:24am] miconda: at kamailio world someone proposed to have sort of backports branch
[11:25am] linuxmaniac: what's that?
[11:25am] miconda: but this would require community involvement, I don't think we have resources to maintain it officially
[11:25am] henningw: there are quite some people still on 4.4, looking to the list questions. I think the same that we don't have ressources for longer or more maintened releases
[11:25am] miconda: linuxmaniac: backporting some of the very useful new featues to the stable branch
[11:25am] miconda: it has the benefits of getting that code tested better
[11:26am] miconda: for example right now, I think db_redis can be used with kamailio 5.1
[11:26am] miconda: I think it doesn't require changes to the core or something else
[11:27am] miconda: so something like: whatever the maintainer of the backports branch considers useful and doesn't break core/config file
[11:27am] linuxmaniac: I don't see the point of having a backport branch. Using an old version means no new features to me
[11:27am] henningw: miconda: I think this is also a question of community involvement for support
[11:27am] miconda: henningw: it is what I said, too
[11:28am] henningw: about backport branch, db_redis is still seeing a lot of changes in the last months, some of them bigger.. Its dificult to decide when to backport and what.
[11:28am] miconda: linuxmaniac: no packaging, or something like that, just someone of taking care of backporting, of course, based on the interest out there
[11:29am] miconda: henningw: of course, might not have been the best example, but the idea is that maybe more people will use/test it when knowing it works on a stable core
[11:29am] linuxmaniac: miconda: I understand but I don't see the point, really. If that is not going to be maintained by us
[11:29am] cchance: would it remain a separate branch, so stable remains stable?
[11:29am] miconda: anyhow, again, it was a proposal from a private discussion I had at Kamailio World and I just remembered about it and thought of discussing
[11:30am] miconda: cchance: yes, stable stays stable
[11:30am] henningw: I think it would be also dificult from a process point of view
[11:30am] miconda: will be like 5.1 (always stable) and 5.1-backports
[11:31am] linuxmaniac: it would be quite dificult to maintain I think ( what goes there and when )
[11:31am] miconda: henningw: I have no personal interest or time resources to do it, it was addressed here to see the interest
[11:32am] miconda: linuxmaniac: who ever want to take over such job, will have the decision power, probably based on proposals, eventually there will be 2-3 coordinators
[11:33am] miconda: but again, nothing that we should do and I am neutral here -- I do not want to do it myself, if others find it useful and want to volunteer for it, I am fine
[11:33am] henningw: i have nothing generally against it, in the end this is something that e.g. bigger companies like 1&1 or other are doing internally anyway
[11:33am] henningw: you can find also many private forks of kamailio on github
[11:33am] miconda: yes, I know
[11:34am] linuxmaniac: sure :-)
[11:34am] miconda: it was also for henningw :-)
[11:34am] henningw: :)
[11:34am] miconda: so, anything else to be discussed?
[11:35am] linuxmaniac: when are we going to be bought by Microsoft then?
[11:35am] miconda: linuxmaniac: we are already, the code in on github and they own it -- we just didn't get a penny for it ;-)
[11:36am] linuxmaniac: :-)
[11:36am] qxork: linuxmaniac: right after we do a special skype module
[11:36am] linuxmaniac: kamailio for business
[11:36am] miconda: open discussions -- any questions
[11:37am] cchance: queue SBC questions...
[11:37am] miconda: ahhh ... I remembered something -- what people think about kamcmd
[11:38am] miconda: shall we keep it in long term?
[11:38am] miconda: now kamctl does rpc commands, kamcmd is a binrpc client interacting with ctl module
[11:38am] linuxmaniac: I think the plan was to replace it with the python one
[11:38am] miconda: it is not like removing it now, but more like what to plan for it
[11:39am] henningw: is kamctl still the "interesting" bash version?
[11:39am] miconda: that binrpc protocol is not documented (afaik), being brewed by the SER devs quite some time ago
[11:39am] miconda: henningw: kamctl does jsonrpc now, still ok
[11:40am] henningw: ok
[11:40am] miconda: kamcli is the python one, with more flexibility
[11:40am] henningw: ok, three tools are indeed a maybe a bit too much
[11:40am] miconda: but kamcli was not really pushed out mutch, so not that popular
[11:41am] henningw: we can put a big "obselete" warning to the output of one of the tools, suggesting to move to a new one
[11:41am] henningw: and then remove it
[11:41am] henningw: after some time
[11:41am] miconda: kamcmd has the rpc command completion, that's the only thing missing in the other
[11:42am] linuxmaniac: you can have it using... let me find it
[11:42am] miconda: personally I have to desire to dig into the code and decode the custom binrpc protocol
[11:43am] miconda: linuxmaniac: kamcmd uses libreadline
[11:43am] miconda: kamcli likely can have it
[11:43am] miconda: not sure about kamctl, being shell
[11:44am] miconda: cchance: did you have some questions to ask? we can do multitasking
[11:44am] linuxmaniac: you already use click in kamcli
[11:44am] miconda: linuxmaniac: yes, kamcli is using click
[11:45am] miconda: linuxmaniac: hopefully you will find some time soon to package kamcli, maybe that will help to make it more popular
[11:46am] cchance: hehe, no, I was referring to the microsoft/skype integration and how it would trigger an influx of "how to configure kamailio as SBC" questions on the mailing list :)
[11:46am] miconda: cchance: :-)
[11:48am] miconda: btw, one thing that we discussed during the past IRC meetings was about kind of collaboration online sessions
[11:48am] miconda: maybe we should try to do it ... I know I said I would try to organize some, but somehow failed
[11:49am] miconda: 2-3 hours of irc/video conf call to address some topic -- like let's convet core cookbook to markdown
[11:49am] linuxmaniac: miconda: hopefully I will
[11:49am] miconda: were couple of guys will sync on doing different parts of it
[11:50am] miconda: linuxmaniac: summer is here, you are going to be bored on the Spanish beach ... :-)
[11:51am] miconda: I think I got all I wanted to discuss ... anyone else?
[11:51am] henningw: nothing from my side for now
[11:52am] cchance: no, all good, have to run now anyway
[11:52am] miconda: cchance: ok, thanks for being here!
[11:52am] qxork: good for me.
[11:52am] cchance: miconda: anytime
[11:52am] miconda: ahh, last one ;-)
[11:52am] henningw: ;)
[11:52am] cchance: spk soon all
[11:53am] miconda: events ... I will be at CluecCon and Astricon, qxork as well
[11:53am] miconda: any other events that people plan to attend or think it would be good to have a presence there?
[11:54am] qxork: I assume I’ll be at ITexpo, but that’s been a little lacking lately
[11:54am] qxork: How is CommCon?
[11:54am] miconda: if anyone here wants to speak about kamailio at a local event, please do it
[11:54am] miconda: you can contact me if you want some assistance with topics, slides, etc ..
[11:55am] miconda: qxork: James Body mentioned my name many times during the past hour, not sure for what, I just choose the wrong room to be in at this time
[11:55am] miconda: otherwise, it is nice, mostly people I know ;-)
[11:56am] qxork: great to hear!
[11:56am] miconda: JB does a persentation about deploying own mobile 3/4G network, so I guess it was about VoLTE/IMS in kamailio
[11:57am] miconda: and quite hot here in UK these days, but I am more that happy with that, although many locals complain ;-)
[11:58am] miconda: ok, so I guess we can consider the meeting finished
[11:58am] miconda: thank you everyone for participating!
[11:58am] henningw: miconda: thank you for organizing it
[11:58am] qxork: Thank you everyone for all the work you do.
[11:58am] surendratiwari3: thanks miconda just bit late
[11:58am] henningw: miconda: do you have a log of the chat to upload to the wiki?
[11:59am] miconda: surendratiwari3: :-)
[11:59am] qxork: I can hit that
[11:59am] qxork: (the log)
[11:59am] miconda: qxork: thanks!
[11:59am] henningw: qxork: perfect
[11:59am] surendratiwari3: please provide us a summary for the same
[11:59am] miconda: surendratiwari3: since you got here, what are your plans for usrloc redis pull request
[11:59am] miconda: ?
[12:00pm] miconda: surendratiwari3: still planning to maintain it or go for db_redis module instead?
[12:00pm] surendratiwari3: need to revisit open issues.will provide the complete fix in this weekend
[12:00pm] miconda: ok
[12:00pm] surendratiwari3: afterwords i am going to work with aerospike</code>