IRC Devel Meeting - 2016-11-08

Date:

Selected: 15:00 UTC, Tuesday, Nov 08, 2016
can attend: dcm qxork vseva
- cannot attend:
Alternatives (add your id if you can attend, or if you want to addend, but you cannot)
Nov 09: dcm vseva
- cannot attend: qxork
Nov 10: dcm qxork vseva
- cannot attend:

Time of the meeting across the world:

16:00 - Berlin, Germany
15:00 - London, UK
10:00 - New York, USA

Utilities:

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
qxork - Fred Posner

Agenda

Kamailio Development Status:

open issues (dcm)
rpm packaging (dcm)

Administration:

community interaction and communication channels

Kamailio 5.0

https://www.kamailio.org/wiki/devel/kamailio-5.0-design
kemi updates
source code tree restructuring (dcm)
roadmap/timelines to next major release (dcm)

Meeting (on site or online/remote sync'ing) for Designing, Coding and Tuning Kamailio 5.0

yes/no?
who?
where?
when?

Minutes

07:00 miconda: hello!
07:01 qxork: @miconda - hello
07:01 miconda: we will start the discussions soon … let’s allow 1-2 minutes more
07:01 qxork: ACK
07:01 miconda: hope everyone is doing well!
07:02 miconda: I know some are busy voting todate, so I hope not to keep this long
07:02 miconda: s/todate/today/
07:02 abalashov: Guten Nachmittag!
07:02 carstenbock: :-)
07:03 miconda: abalashov: berlin had a perfect weather for your taste this autumn … you should have come around this time
07:03 qxork: I guess that means no humidity
07:03 carstenbock: Hamburg is covered in snow....
07:04 miconda: carstenbock: keep that there for a while, don’t let it south ;-)
07:04 abalashov: miconda: Berlin nearly always has perfect weather for my taste, except the warmer times in summer.
07:05 miconda: abalashov: quite often it’s not much summer around anyhow
07:05 miconda: ok — I guess we can start
07:05 qxork: =)
07:05 miconda: as usual, first are the major issues
07:05 miconda: if there is something that people feel is not working as it should
07:05 miconda: code or admin wise
07:06 miconda: ok … so nothing reported here
07:06 miconda: I spent some time with code analyzers lately, in preparation to relocate files for 5.0, thinking that backporting later might be more dificult
07:07 miconda: I usually do it during the testing period, but this time I did another session earlier
07:07 abalashov: I have something I wanted to discuss, but I did not manage to put it on the agenda.
07:07 abalashov: It relates to mhomed=1 behaviour.
07:07 abalashov: I can also just post about it later if now is not the appropriate time.
07:08 miconda: abalashov: you can describe it shortly, let’s see if we can get something now
07:08 miconda: if not, later ...
07:09 abalashov: Basically, if an interface has a primary and a secondary IP both on the same subnet.
07:09 abalashov: mhomed doesn't seem to make intelligent decisions about which source IP to send it from.
07:09 abalashov: Even if the appropriate constraints are set in the routing table.
07:10 eschmidbauer: is live reload of .cfg planned for 5.0 release?
07:10 abalashov: Or, let me rephrase that.
07:10 abalashov: Multiple _interfaces_ with IPs on the same subnet.
07:10 abalashov: As sometimes happens in complex topologies.
07:10 miconda: eschmidbauer: yes, if you write routing rules in lua (via so called kemi interface)
07:11 eschmidbauer: ok, so only if you write your routing logic in lua ?
07:11 abalashov: The interface detection algorithm should set the source IP to each of the registered listener addresses. Otherwise you could potentially get a completely different address on one of those interfaces in the utility function that figures out the interface to use.
07:11 miconda: abalashov: afaik, mhomed triggers creation of tmp sockets to see if the kernel complains for routing
07:11 qxork: abalashov: even with setting a $fs or similar?
07:11 abalashov: qxork: No, the intent here is to avoid explicit steering with $fs as it would be too labourious.
07:12 qxork: abalashov: understood
07:12 abalashov: miconda: So, in other words, if you try to route to $SOME_REMOTE_SUBNET that's not directly connected in the local routing table, Kamailio gets confused because that remote subnet is not in the listener list.
07:12 miconda: abalashov: but this will require a more detailed description of the interfaces setup, what happens and what should happen
07:12 abalashov: Even though the local system's routing table describes what should happen.
07:13 abalashov: Okay, I'll take it to the lists later with a more detailed description.
07:13 miconda: abalashov: ok, I think it requires code investigation, so the best is to open an issue on bugtracker
07:13 abalashov: Okay.
07:13 abalashov: Sorry, I figured it might be a bit too esoteric for this meeting.
07:14 miconda: we tried ;-)
07:14 miconda: something else - anyone?!?
07:15 abalashov: qxork: Imagine a system with like 5 IPs on 3 interfaces. You don't want to guide everything with $fs there.
07:15 qxork: just good feedback =)
07:15 miconda: next will be (again) if anyone here has interest in becoming maintainer of (or helping with) rpm packaging
07:15 qxork: abalashov: understood completely and looking forward to following this
07:15 abalashov: qxork: The desire would be to have Kamailio just do the right thing magically, assisted by the local routing table's policy routing rules.
07:15 miconda: there was a pull request recently on updating the rpm specs for centos
07:15 abalashov: qxork: Becomes important in a lot of weird "cloud" and "SBC" applications of Kamailio.
07:15 miconda: so I guess people use rpms
07:16 abalashov: miconda: They do, even though they really shouldn't. ;-)
07:16 miconda: I package them, but don’t use, so it might not be the best outcome (e.g., hard to see if something get’s broken)
07:17 miconda: and to finish with the admin part — anyone wanting something new to be used for collaboration within the project
07:18 miconda: or we are fine with the mailing lists and irc channel, plus the github.com tools for bugs and pull requests ...
07:18 abalashov: To my own surprise, Github has proven fairly adequate for this, at least in my eyes.
07:18 abalashov: If nothing else, the integration with the repo and the rest of the workflow is valuable.
07:18 abalashov: cresl1n: Privet!
07:18 iZverg: I had same schema: Asteridk registered on K. Call came on K. with "To: NUMBER@KAMAILIOIP". after forward A. receive same "To:", but I need "To: NUMBER@ASTERISKIP".
07:18 qxork: seen a lot more recent activity on irc...
07:18 miconda: abalashov: indeed, at least handling contributions is easier
07:18 cresl1n: abalashov: You're on IRC!
07:19 cresl1n: Dobroye utro :-)
07:19 carstenbock: Unfortunately, my colleague Marcel cannot join today.
07:19 abalashov: iZverg: That can be accomplished with the uac module's uac_replace_to(), if it absolutely has to be, though it's generally hacky and theoretically undesirable if it can be avoided.
07:19 miconda: qxork: good to hear that, I was a lot of time traveling in the past months, so not much active on irc
07:19 abalashov: iZverg: But it works well.
07:20 carstenbock: He could help with RPM Packaging, he spent some time updating the RPM specs for our VoLTE and WebRTC setups....
07:20 miconda: carstenbock: ok, noted that … will ping you for a reminder to see what can be done here
07:21 carstenbock: (Operators love RedHat)
07:21 iZverg: abalashov: ok, thank you. I don't know why, but A. regged on K. has ugly context in rare cases...
07:21 abalashov: miconda: I agree, there's a lot of value in just using what's already built in without having to integrate or have information scattered across disparate tools.
07:21 miconda: ok, if no new suggestion for project collaboration, then we can move to next big topic — kamailio 5.0
07:21 abalashov: miconda: I am certainly much more inclined to submit issues now that I don't have to figure out where FlySpray lives for the thousandth time.
07:22 miconda: abalashov: :-)
07:22 miconda: abalashov: I thought there were no issues to report, not lack of knowing where :-)
07:22 abalashov: :D
07:23 miconda: ok then — kamailio 5.0
07:23 miconda: first — some update from my side
07:23 abalashov: Live config reloading is of course a hot topic, and I understand the complexities of reloading the native route script given how deeply its actions and state are seeded in runtime.
07:23 abalashov: But I wonder if perhaps there is some means of "isolating" it similar to the Lua approach.
07:23 miconda: kemi framework is implemented for lua and python
07:24 abalashov: Making it "relocatable" or "reloadable".
07:24 abalashov: Or maybe that would require rewriting Kamailio. :-)
07:24 qxork: I'm torn on reload (live reload)
07:24 miconda: for those not familiar - kemi is the framework that allows writing routing logic in different scripting languages
07:25 miconda: now supported for native kamailio.cfg, lua and python
07:25 abalashov: qxork: It would be genuinely _complicated_. You'd have to figure out what to do with existing open transactions, dialogs, associated variables, messages in process...
07:25 qxork: I see the request side... but at the same time, there are many tools/modules to be able to reload or make live needs happen
07:25 miconda: I guess we need also javascript to match today’s world expectations :-)
07:25 abalashov: miconda: Oh god.
07:25 qxork: My thought would be a better approach to ones config would eliminate most needs of a live reload.
07:26 abalashov: qxork: I generally agree, but sometimes it just can't be helped, i.e. things get hard-coded for performance reasons.
07:26 abalashov: miconda: The true holy grail would of course be live reloading of native kamailio.cfg in entirety.
07:26 abalashov: miconda: But I think you ruled this out in the past.
07:26 qxork: abalashov: agreed... which is a design consideration =)
07:27 miconda: abalashov: with a certain level of rewriting (maybe 99% of the config interpreter), that can be possible of course
07:27 abalashov: qxork: Also keep in mind there are very complex kamailio.cfg's which can be generated from templating engines using 'dynamic' parameters... this is a common approach where performance without waiting on DB I/O or things like that is an important consideration.
07:27 abalashov: miconda: That's a pretty high level of rewriting. ;-)
07:27 volga629_: I think kamailio need live console
07:27 volga629_: like freeswitch or asterisk
07:27 miconda: abalashov: but the thing I see more important is performance of an interpreter with static pre-compilation, vs the interpreter that can reload
07:28 abalashov: volga629_: It kind of has that, in the form of its management/RPC APIs. 'kamcmd' essentially behaves this way, it just doesn't have the ncurses CLI that gives asterisk -r or fs_cli its "live console feeling". If you think about it, fs_cli talks to FS entirely via ESL.
07:28 qxork: miconda/abalashov: +1
07:28 abalashov: miconda: I agree with that strongly.
07:28 miconda: because if we lose too much of the performance, then makes no sense
07:28 abalashov: miconda: And that necessarily requires stuff deeply embedded into runtime.
07:28 abalashov: miconda: Stuff that can't be easily reloaded like that.
07:29 miconda: maybe in the future, we can write a second kamailio.cfg interpreter, with reload support, as an alternative to the existing one
07:29 abalashov: Yep -- the native config script exists because it's the fastest approach, it simply beats any other config approach.
07:29 abalashov: And that is a value-add that should stay.
07:29 qxork: agree strongly
07:30 miconda: at the end, if we look only at routing blocks, we need to work around the fixup of the parameters
07:30 abalashov: miconda: I just wanted to hear you say it would take 99% rewrite. :)
07:30 abalashov: Yeah, there's all kinds of complications I didn't even think about at the first pass.
07:30 miconda: abalashov: that’s about the config interpreter, not the entire kamailio
07:30 abalashov: There's a lot of what is essentially "static code analysis" that goes on on boot.
07:30 abalashov: miconda: Yeah, I know.
07:31 abalashov: That's what I meant.
07:31 miconda: abalashov: it will be more of taking each config function and be sure it can deal ok with doing fixups at runtime
07:31 osas: another option would be to have the ability to reload a route (when a small change is done inside an existing route)
07:31 abalashov: osas: But calls to e.g. module functions have fixups there too.
07:32 qxork: Well, if they switch to using lua lets say... this eliminates a lot of need for the reload, no?
07:32 abalashov: qxork: As long as they're willing to compromise performance and to use Lua. There's a certain appeal to having a reloadxml-like cake you can eat too. And you know all about cakes.
07:32 miconda: qxork: you can do reload of lua script that has the routing blocks
07:32 qxork: abalashov: and eating
07:32 miconda: useful links: https://www.kamailio.org/wiki/devel/kamailio-5.0-design
07:33 osas: abalashov: yes, but probably does not require a new cfg interpreter
07:33 volga629_: console will give ability reload separate module and with it configuration or reload all. Also you can control visually what is go in on when reload in progress
07:33 iZverg: K. 5.x still has unfixed CPU issues on FreeBSD...
07:33 abalashov: volga629_: Well, a console cannot provide functionality that isn't otherwise there simply because it is a console. :-) A "live console" is a description of a particular kind of user interface/"user experience", not so much a vivid descriptor of what it can do.
07:33 miconda: kemi: https://www.kamailio.org/wiki/devel/config-engines
07:34 qxork: I can see some fun performance testing of taking existing configs and testing as .cfg, lua, python, etc.
07:34 abalashov: miconda: Has any picture emerged of what a continuous integration pipeline might look like?
07:35 abalashov: qxork: Well, if fun is what you call that ...
07:35 miconda: abalashov: lua is calling kamailio functions directly (no complex layer in between)
07:35 miconda: the only difference is on parameter evaluation
07:35 abalashov: Ahh.
07:35 abalashov: That's good to know.
07:35 miconda: in kamailio.cfg is done through the fixup system
07:35 abalashov: So perhaps Lua config is not as slow as I imagine it.
07:35 miconda: in lua.cfg is done by lua operations
07:35 abalashov: My mental picture was somewhere on par with app_perl.
07:35 qxork: abalashov: it's taken me years to appreciate lua
07:35 miconda: but in both cases a parameter reslves to an integer or a string
07:36 miconda: and calls the base function in c
07:36 miconda: so for kamailio.cfg interpreter we have wrapper functions that evaluate the parameters from fixup form to these int or string values
07:36 abalashov: miconda: If that's the case, then why is it easier to reload?
07:37 miconda: because lua doesn’t pre-compiles parameters in pkg
07:37 abalashov: miconda: Just because the execution is still a call out to a reloadable Lua codebase in the end, not "static" in the way native cfg is?
07:37 abalashov: Ah, so it's all got to do with the fact that the parameters are all left floating/dynamic?
07:38 miconda: abalashov: more or less yes
07:38 abalashov: But how is the handling of existing in-flight transactions and dialogs and other state accomplished?
07:38 miconda: abalashov: writing a new interpreter might be easier that just making the old one in dual mode
07:38 miconda: the code can be even simpler
07:38 miconda: I mean a new interpreter for kamailio.cfg with reload capability
07:39 miconda: abalashov: it will have to do lookup at the moment it needs to execute the routing block
07:39 abalashov: So what happens if I have a message that's in the middle of winding its way through a worker at the time the reload is issued?
07:39 miconda: for example: right now we resolve a failure_route[xyz] to its pointer in memory
07:39 abalashov: Or am waiting on an fr_timer and a pending failure_route?
07:40 miconda: for lua (via key), we keep the name of the function to be executed
07:40 abalashov: Ahhh.
07:40 miconda: that can be done also with a c interpreter
07:40 abalashov: Well, you'd still have to deal with the target function simply going away.
07:40 miconda: but don’t optimize at startup
07:40 abalashov: And things like that.
07:40 miconda: that’s ok, even now it works if the failure route block is not found
07:41 miconda: but I think we have some check at startup
07:41 abalashov: You do.
07:41 abalashov: I can't get Kamailio to start with a nonexistent failure_route armed.
07:41 abalashov: So I assumed that was quite 'static' as well.
07:41 miconda: but we can print a log message at runtime if the routing block is not found by interpreter
07:42 hughw: Hello.
07:42 miconda: we ca still check when we parse the config file, so we can (always) do some optimizations
07:42 abalashov: miconda: So what is the prospectus for a new native cfg interpreter that works on the principle of keying functions and other referents by key rather than by memory address?
07:42 miconda: like keeping versions of the config file and along he name keep the version and a pointer in memory to the routing block, then when executing, if the version is the same, run directly, otherwise, lookup again
07:42 abalashov: miconda: Is it something you might be willing to do for 5.0?
07:43 hughw: If we are upgrading individual routing blocks at runtime, do we need to keep the old version of the block until all references to it (transactions) have gone
07:43 miconda: still extra checks will be done, so it will not be same kind of complexity at runtime like with old interpreter
07:43 abalashov: hughw: That could get complicated quickly.
07:43 abalashov: hughw: Endless reference counts for an increasingly large number of entities...
07:43 hughw: e.g. is someone sets t_on_failure(MY_ROUTE) and then the route is changed before the reply comes back
07:43 miconda: hughw: the current approach with lua configs (via kemi) is to keep names instead of pointers, with lookup at runtime
07:44 abalashov: hughw: What do you do with things like event_route[xhttp:request] and etc?
07:44 abalashov: Version and refcount absolutely everything?
07:44 abalashov: What if xhttp module is unloaded and this event_route is no longer provided? :)
07:44 miconda: hughw: actually in the lua, there is no failure_route concept, but providing a callback function name to be executed
07:44 hughw: True
07:44 miconda: abalashov: reloading the modules will make it a lot more complex
07:45 abalashov: I mean if it's simply not loaded in the new config.
07:45 abalashov: But we have referents going to custom routes provided by modules.
07:45 miconda: we are targeting reloading the runtime active parts — the routing blocks
07:45 miconda: because for modules, they create connections to backends, load data at startup, etc …
07:45 abalashov: Sounds like a real mess. Hard to reason about. Maybe easier for you -- if so, that is very fortunate ...
07:45 miconda: this may be ng-ng-ng version
07:46 miconda: so to summarize ...
07:46 abalashov: Well, the other thing you have to consider is, if the approach to reloading taken is to drop lots of state altogether, then at some point you have to ask what is the benefit of live reloading versus restarting.
07:46 abalashov: In other words, what is "live" about it? :)
07:46 miconda: getting an interpreter that can reload routing blocks might not be that complex, but it requires a lot of walk through the exiting functions and adapt them to work in both modes
07:47 miconda: changing the current interpreter might not be the easiet option, so writing an alternative can be better
07:47 abalashov: miconda: What is your level of eagerness to write such a new alternative on a scale of 1 to very eager?
07:47 miconda: but I don’t expect to add much more performance than a lua interpreter, but I don’t say it is something that should not be done
07:48 qxork: I'd love to see this put off to Kamailio 6
07:48 miconda: abalashov: probably I can get one as core framework, but I don’t want to walk all the kamailio mdules to be sure the functions are safe to be used there
07:48 abalashov: qxork: KamailioWorks R13 you mean?
07:49 qxork: ;)
07:49 miconda: we have the fixup + fixeup_free functions, they are used by python/lua (oldstyle, not via kemi)
07:49 abalashov: miconda: I'd say let's shelve that idea for KamailioWorks R13 then.
07:49 abalashov: Not everything that can be done is worth doing just because it can be done. We're not OpenSIPS.
07:50 miconda: for example: app_python can call any module function doing fixup before execution, then free fixup after return
07:50 qxork: I truly believe that what we have is great in terms of performance / function
07:50 miconda: but I expect some of the functions don’t have the free fixup
07:50 abalashov: qxork: You mean to say ... we've Made Kamailio Great Again?
07:50 qxork: some changes must require either a loss of a call or a maintenance window
07:50 miconda: as a matter of fact, right now there is insignificant difference between lua (kemi) and native interpreters
07:50 carstenbock: :-D
07:51 qxork: We're going to build a great big reload. Beautiful.
07:51 qxork: It's going to be huuuuge.
07:51 miconda: as i said, what they do different is how they build the int/string parameter values
07:51 miconda: the execution of the base c functions is done the same
07:52 abalashov: qxork: Can we get Oracle to pay for it?
07:52 miconda: the lookup of failure/branc/onreply_route blcoks is very fast
07:52 miconda: because typically a kamailiocfg has only few of them
07:52 abalashov: nods
07:52 miconda: say 5-10 failure route blocks
07:52 abalashov: That's way more failure_route blocks than I ever had.
07:53 miconda: abalashov: it’s not about route blocks, but failure route … do you have lot more?
07:53 miconda: they are anyhow indexed by hash id (iirc)
07:53 miconda: some of the modules even do runtime lookup for event_routes …
07:54 miconda: anyhow, let’s get to a conclusion here
07:54 abalashov: New interpreter not needed at this time.
07:54 abalashov: But intriguing discussion and worth keeping in mind for future.
07:54 abalashov: That would be my interpretation.
07:54 qxork: agreed. new interpreter not needed at this time.
07:54 miconda: my approach is to have lua and python on pair if the most of available config functions (I mean most relevant modules)
07:55 abalashov: nods
07:55 miconda: because then it will be easier to write a kemi interpreter in c
07:55 abalashov: If someone really values reloadability that much ... use kemi.
07:55 qxork: thumbs up
07:55 abalashov: OH. I just remembered something ... this may not be the right part of the discussion for it ...
07:55 abalashov: But I was very surprised to discover recently that I can't drop replies in transaction-affiliated (TM) onreply_routes.
07:56 abalashov: Only in the global onreply_route.
07:56 abalashov: But I don't want to drop all replies, only some.
07:56 abalashov: This has led to the need for a complex and somewhat imperfect htable-based statekeeping mechanism to know for which Call-IDs to drop which replies.
07:56 miconda: other benefits I see when using lua/python/… is the extensive language syntax (even ignoring t their extensions/libs)
07:56 abalashov: Any chance this can be addressed?
07:57 miconda: abalashov: open an issue on tracker to discuss it
07:57 miconda: afaik is only the 2xx that cannot be dropped
07:57 abalashov: Okay. The reason I brought it up here is I wondered if there is some technical obstacle.
07:57 abalashov: Yes, that's right. But it is precisely 2xx replies I need to drop. :/ (It pertains to transactions for which I've already sent 2xx replies from Kam, and then suspended to wake up later...)
07:57 miconda: it’s open source, if something is not there, then a PR was not received :-)
07:58 miconda: I am sure it can be addressed
07:58 abalashov: So is there some technical reason why 2xx replies cannot be dropped that goes deeper than if(reply_code >= 200 && reply_code \<= 299) { disallow drop for arbitrary reasons }?
07:58 abalashov: That was the real question.
07:58 miconda: eventuall with another event route pre-transaction status update
07:59 abalashov: Ah, but I want the received 2xx reply to close out the transaction. I just don't want to send it back to the UAC.
07:59 miconda: the thing to see is where the onreply route is executed
07:59 miconda: if it’s executed before updating the state of transaction, then should be no problem
07:59 miconda: but maybe right now is after
08:00 miconda: 3xx+ codes are easy to drop, becaue we drop anyhow some of them in case of serial/paralel forking
08:00 abalashov: I would want the 2xx reply received from UAS to affect transaction state, but just suppress its forwarding to the UAC.
08:01 abalashov: If there were something like an onsend_route or something low-level where I can just block it before it goes out on the transport level...
08:01 miconda: abalashov: isn’t that working with onsend_route for replies?
08:01 abalashov: miconda: Can I drop stuff there? And aren't those global, not transaction-associated?
08:01 miconda: I think I told you about
08:01 abalashov: That may be, and the fault may entirely be mine.
08:01 miconda: they are global
08:01 miconda: but you can still check avps/flags there
08:01 miconda: which are per transactions
08:02 hughw: In the cfg, there is a check to ensure you are allowed to call certain functions in the route type. Or the function behaves differently (internally) depending on which route it was called from.
08:02 hughw: Does the same check work when calling functions from LUA?
08:02 abalashov: iZverg: How would I check transaction-affiliated flags or AVPs there if the onsend routes for replies are not transaction-bound?
08:02 abalashov: Sorry, miconda: How would I check transaction-affiliated flags or AVPs there if the onsend routes for replies are not transaction-bound?
08:03 miconda: hughw: afaik, before executing a failure_route, tm sets the type of routing block
08:03 miconda: this hasn’t changed
08:03 miconda: instead of executing the native failure_route, it tells to kemi to execute a function
08:03 miconda: but setting the routing block type is done before, not changed
08:04 miconda: abalashov: it’s still in the context of that sip message
08:04 abalashov: miconda: OH
08:04 abalashov: miconda: It seems I misunderstood this.
08:04 hughw: (I've been away from kamailio development for a bit - probably should do some revision)
08:04 miconda: onsend_route is executed inside t_relay()
08:04 abalashov: miconda: That may be an elegant and simple solution to the problem then, will test.
08:04 abalashov: miconda: Oh! I thought it was global similarly to onreply_route global.
08:05 miconda: hughw: you are very welcome back! I expect you will like the kemi approach, afaik, you use a lot of lua with kamailio.cfg
08:07 qxork: what's next?
08:08 miconda: next will be restructuring the location of the code
08:08 miconda: I think we decided that
08:08 miconda: the question is if anyone knows any too/script that can help with that
08:08 miconda: we will aim at:
08:08 miconda: src/
08:08 miconda: src/core/
08:08 abalashov: startledmarmot: Hello!
08:08 miconda: src/modules/
08:08 miconda: src/libs/
08:09 miconda: the root folder should have the docs/, maybe etc/ and test/
08:09 miconda: plus a single master Makefile
08:09 abalashov: miconda: Would it be asinine to suggest Bash as a tool for this endeavour? :-D
08:09 miconda: all the other makefiles moved to src/
08:10 qxork: I think I was supposed to look at a perl script for this and dropped the ball
08:10 miconda: also in root folder have the main README and INSTALL …
08:10 miconda: so the root folder looks a bit cleaner
08:11 miconda: also, we will get all core related components in a place where is easy to spot them (i mean heare the mem, parser, … folders — they will be moved in the src/core/)
08:11 miconda: abalashov: waiting for that bash script now :-)
08:12 hughw: don't forget /pkg for the RPM spec files
08:12 miconda: well, I guess one can do it with perl. sed. awk, etc … I was more looking to see if anyone is aware of an existing tool
08:13 miconda: where one ca say: file x.h moved from . to src/core/ — update all the exiting includes :-)
08:13 miconda: hughw: sure, there are several folders to be still kept there
08:14 miconda: so no one knows such tool, we will have to write one
08:14 miconda: or use vim+keyboard
08:14 miconda: next topic
08:14 abalashov: nods
08:14 abalashov: That follows well-understood UNIX src project structure.
08:14 abalashov: Do module docs stay in the modules' respective subdirs?
08:14 abalashov: Or go in docs/ ?
08:15 miconda: abalashov: docs for modules will stay in the same folder, like now
08:15 startledmarmot: abalashov: what's up bud!
08:16 miconda: back to next topic
08:16 miconda: anyone knowing a document format (markup language) for defining function prototypes
08:17 miconda: it may be useful to use one to be able to get the list of exported functions
08:17 miconda: not thinking only of kemi functions as I emailed a while ago, but this can be useful for rpc commands as well
08:18 abalashov: You mean something that can analyse code and retrieve a list of all function prototypes, despite complex multiline formatting and so on?
08:18 miconda: as osas noticed, rpc commands are not well indexed and documented
08:18 miconda: abalashov: more the other way around
08:18 miconda: have a spec file and then generate c code to be included by module
08:18 abalashov: Ahh. Like stubs.
08:18 abalashov: Can't generate implementations obviously. ;)
08:19 miconda: abalashov: what you say it’s done for extracting rpc commands
08:19 miconda: but requires some patches to a perl module plus a specific compiler mode
08:19 qxork: brb
08:19 miconda: abalashov: yep, like stubs
08:19 abalashov: So you're looking for something that can generate rpc functions consistently for all modules ... do these functions have a body of some kind, or just empty stubs?
08:19 miconda: abalashov: or only the prototypes
08:20 miconda: abalashov: only function prototypes and interface structures
08:20 miconda: I don’t want to go that far in defininf function stubs
08:21 abalashov: Ah.
08:21 carstenbock: We should add it also for PV's and Transformations... the Wiki-Page is not always complete.
08:21 osas: maybe a custom awk script?
08:21 miconda: something that I can use to generate c code with the ptototypes and the interface structures, as well as documentation index
08:21 abalashov: But what's the use in a prototype if the functions are not implemented? Or am I misunderstanding?
08:21 miconda: I don’t see it as a replacement for existing docs
08:22 miconda: but something that can be easily checked to see if a function is not documented
08:22 carstenbock: Got to go: My son is waiting... CU all!
08:22 abalashov: Ahhh.
08:22 miconda: carstenbock: thanks for participating, will keep in touch for rpms!
08:22 osas: I would say we should use it to generate both prototypes and xml docs
08:23 abalashov: So it does pull stuff out of existing code. The idea is to discover RPC functions which exist and display them in some format?
08:23 miconda: osas: maybe parts of xml docs
08:23 miconda: but I don’t want to have examples there
08:23 osas: miconda: yes :)
08:23 osas: only the RPC part
08:23 abalashov: I find system.listMethods to be pretty insightful. Most stuff is fairly obvious. But yes, in cases where parameters are required, not always.
08:24 eschmidbauer: is it possible to update presentity from another module without using DB?
08:24 miconda: abalashov: let me give some example
08:24 miconda: when adding a new function, instead of writing c code to define it’s prototype and add it to the module exports structure
08:24 abalashov: miconda: Please. :-) It seems I am a bit confused about the direction of the analysis.
08:24 miconda: just write in a spec file
08:25 osas: and add the actual code for it :)
08:25 miconda: run a tool on that spec file that will re-generate a .h file and a .c file
08:25 eschmidbauer: you know what would be awesome.... a gRPC module
08:25 abalashov: So where does the actual code for it come from? ")
08:25 abalashov: Is that in the spec file too, or is that up for you to write between the curly braces of the stubs?
08:25 miconda: it will be generated by the tool
08:26 miconda: the implementation will be in another c file
08:26 abalashov: Is that based on the theory that most RPC operations are really simple?
08:26 abalashov: Oh.
08:26 miconda: so the module exports will include the h file and only the generated structure
08:26 miconda: implementation will be in another c file
08:26 miconda: all linked at compile time
08:26 abalashov: But to be clear, the implementation is still up to you to write... you're not talking about partly generating implementations of any kind, just signatures?
08:26 miconda: so the mod exports c file will be only with exported structures
08:27 miconda: abalashov: yes
08:27 abalashov: cresl1n: Know of anything like this?
08:27 abalashov: mjordan: Or you?
08:27 osas: while generating the .h files, we should generate the includes in the xml doc file too
08:28 miconda: iirc, Henning Westerholt proposed something like that in the past
08:28 miconda: osas: right
08:28 abalashov: miconda: If nobody has any suggestions, my suggestion is to use a YAML input file and feed it to j2cli, which uses the Python "jinja" template engine, if you have any familiarity with it.
08:28 abalashov: miconda: j2cli just provides a CLI wrapper for it.
08:29 osas: BTW, when are we going to drop the mi interface?
08:29 miconda: abalashov: ok, I will look into it
08:29 abalashov: miconda: "jinja" is a bit of an annoying dependency (pyYAML etc.), but is very easy to use for something like this IMHO.
08:29 miconda: I wanted to get some leads
08:29 miconda: abalashov: it will be used only by devs, I think that’s ok
08:29 abalashov: https://pypi.python.org/pypi/j2cli/0.3.0-0
08:29 abalashov: I've been very happy with it.
08:29 abalashov: I got into Jinja because of SaltStack.
08:30 abalashov: It's just very easy ... {% for f in rpcFuncs %}dothings{% endfor %}
08:30 abalashov: YAML -
08:30 abalashov: rpcFuncs:
08:30 abalashov: - rpcCall
08:30 abalashov: arg1: x
08:30 abalashov: arg2: x
08:30 abalashov: You get the idea.
08:30 miconda: yep
08:30 miconda: ok, we have a lead
08:31 abalashov: Just really simple if you don't want to learn something complicated and esoteric.
08:31 abalashov: It's become my favourite templating tool because of its simplicity.
08:31 abalashov: It's like the opposite of m4.
08:31 miconda: and people got the idea, so they can email if they have new suggestions
08:31 abalashov: osas: Never!
08:32 miconda: abalashov osas :-)
08:32 miconda: regarding the mi, the main concer is getting kamctl on pair when using rpc
08:32 mjordan: abalashov: apologies, trying to catch up. What opinion were you soliciting? :-)
08:32 miconda: we have kamctl, maybe that’s a way to push further
08:33 abalashov: mjordan: Opinion on a tool that can take list of functions from a spec file --> generate function signatures/prototypes and source stubs for it.
08:33 mjordan: we use jinga2 templates
08:33 abalashov: mjordan: jinja2 you mean?
08:34 abalashov: mjordan: By coincidence, that's exactly what I was just suggesting above. I got into jinja because of SaltStack and decided it's the hammer for all my nails everywhere else too.
08:34 mjordan: Ah, I'm actually wrong - we used that elsewhere. For ARI, we use Swagger for the specification, a Python script to read that specification, and mustache templates to generate the C/H files
08:34 miconda: otherwise I am using more rpc because of better structured format, so not much tied to old mi
08:34 abalashov: mjordan: https://pypi.python.org/pypi/j2cli/0.3.0-0
08:34 abalashov: miconda: I've switched to rpc entirely.
08:35 mjordan: Really, though, something like mustache or jinja should be sufficient. We generate some relatively complex binding files from the HTTP server to the ARI logic
08:35 abalashov: Any particular reason you didn't go with Jinja but instead what sounds like a house-brand Python script?
08:35 miconda: mjordan: thanks, I will check those as well
08:36 mjordan: example of a generated file: http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=blob;f=res/res_ari_bridges.c;h=29fb07582deb79a04e8a38a42547bd3860263b3a;hb=refs/heads/master
08:37 mjordan: abalashov: yeah, we use j2cli to manipulate configuration files in Docker containers. Long story :-)
08:37 abalashov: mjordan: The world is small.
08:37 qxork: was hoping to go another 10 min before hearing about docker ;)
08:37 abalashov: mjordan: I didn't think anyone else thought jinja2 was cool.
08:37 mjordan: abalashov: does this mean we're both hip now?
08:38 abalashov: qxork: Docker is dead, long live RKT.
08:38 abalashov: mjordan: Oh no, you actually _use_ Docker ... you're much more hip.
08:38 qxork: abalashov: oh my testing as fun is not cool, but your jinja2 is ... I see how you are. =)
08:38 abalashov: Testing is fun when it's miconda's patience.
08:39 abalashov: (for off-topic blather)
08:39 qxork: smiles loudly
08:39 miconda: abalashov: I only test (I cannot afford to have another server to run production)
08:39 miconda: :-)
08:40 miconda: so … let’s move to the last topic
08:40 qxork: production is just another form of testing
08:40 scv: lol
08:40 miconda: roadmap to 5.0
08:40 abalashov: qxork: Glad someone else agrees.
08:41 miconda: I was thinking of freezing just before Christmas holidays
08:41 miconda: or sometime in January
08:41 miconda: a matter of how code restructuring goes on
08:41 miconda: because I want to do it just before freezing
08:41 miconda: to have fixes still backported in an easy way
08:42 miconda: afterwards I will expect conflicts and not that easy to backport
08:42 miconda: after freezing, go with the ususal 1-1.5 months of testing
08:42 miconda: and release
08:42 miconda: not sure if we will make it with 5.0 in the next debian stable
08:43 qxork: with git, we make all distros
08:43 abalashov: qxork: +1
08:43 miconda: maybe linuxmaniac can shed more light when debian freezes the acceptance of new versions of packages
08:43 abalashov: miconda: That also implies that a next major .0 release of something is stable. ;)
08:44 miconda: abalashov: besides relocating the code, won’t be any major changes
08:44 abalashov: Sorry, it's a lot easier to make funny jokes than to submit PRs.
08:44 miconda: the kemi framework proved to be really not intrusive
08:45 miconda: abalashov: I like to hear more jokes than seeing new issues opened on the tracker :-)
08:45 linuxmaniac: miconda: https://wiki.debian.org/DebianStretch
08:45 linuxmaniac: > 2017-01-05: "Soft" freeze (no new packages, no re-entry, normal migrations)
08:46 miconda: so all this restructureing for 5.0 will be more like labor work, than rocket science
08:46 miconda: linuxmaniac: can we be there with a 5.0.0-pre
08:47 miconda: and get 5.0.0 as it gets out, through the usual patch update?
08:48 linuxmaniac: not really
08:48 linuxmaniac: sorry
08:48 linuxmaniac: yes, we can
08:48 miconda: linuxmaniac: ok — we will see what can be done, it’s good to have the dates in mind
08:49 linuxmaniac: but we need 5.0.0-pre before that date at stretch already
08:49 linuxmaniac: no new modules
08:50 linuxmaniac: just normal new version
08:50 miconda: linuxmaniac: so some will have a busy winter holidays :-)
08:50 linuxmaniac: indeed
08:50 miconda: linuxmaniac: yes, that’s doable, freezing before that date in kamailio
08:51 abalashov: Unfortunately I've got to run ...
08:51 linuxmaniac: abalashov: la vida!
08:51 miconda: I haven’t seen oej around, but I guess that idea of a face to face meeting was dropped
08:51 qxork: abalashov: always a joy to see you
08:51 abalashov: linuxmaniac: Pura vida che!
08:51 miconda: abalashov: thanks, very useful input this time :-)
08:51 qxork: miconda: this time. ;)
08:51 linuxmaniac: not like normally, :-P
08:52 abalashov: :D
08:52 miconda: :-)
08:52 abalashov: Now I'm in pain ... have to recover. It hurts so much to give useful input.
08:52 abalashov: I'll see you next week
08:52 linuxmaniac: cu!
08:52 miconda: I think I run though all my main topics
08:53 miconda: if anyone has anything else to discuss … you are welcome to step forward
08:53 qxork: what additional assistance do you need?
08:54 qxork: aka... how else can we help?
08:54 miconda: qxork: two more hands won’t be bad :-)
08:54 miconda: and a brain :-)
08:55 linuxmaniac: miconda: lately I'm really busy
08:55 qxork: =)
08:55 miconda: linuxmaniac: that’s ok, get that done
08:55 linuxmaniac: I hope so!
08:56 miconda: hopefully people will get involved in helping with relocation of code files
08:56 miconda: that would be very helpful
08:56 miconda: should not be anything complicated
08:56 linuxmaniac: can we manage to arrange a remote dev metting to work on that?
08:56 miconda: just wrting some scripts, with good regexps around
08:57 miconda: linuxmaniac: what you think of?
08:57 miconda: some video conf?
08:57 linuxmaniac: no need at all.
08:57 linuxmaniac: just IRC and some pastebin
08:58 linuxmaniac: prepare the scripts
08:58 linuxmaniac: and do some tests
08:58 linuxmaniac: before the big change
08:59 qxork: I can offer a server if you want for the conf, unless you plan on using jitsi meet, hangouts, or something else.
09:00 miconda: linuxmaniac: let’s try via mailing list to see we can get some people interested to participate and get a date for it
09:00 linuxmaniac: ack
09:01 miconda: qxork: I guess will take us some time to setup the server, probably jitsi meet will do it if needed
09:01 miconda: we can use the time for writing the scripts
09:01 linuxmaniac: I can ask some for some help of any sipwise's perl guru
09:01 qxork: miconda: ack. won't drop the ball this time.
09:01 cresl1n: abalashov: Sorry about the delay, just got off of a long call. What's up?
09:02 qxork: cresl1n: he had to run
09:02 cresl1n: ic ic
09:03 miconda: cresl1n: I guess mjordan answered what abalashov wanted
09:04 miconda: cresl1n: which was about tools used to generate function signatures/stubs/interfaces from a template file
09:04 linuxmaniac: miconda: is anyone working on sca apart of me?
09:04 cresl1n: thanks miconda
09:05 cresl1n: are you doing well?
09:05 miconda: linuxmaniac: i think it was another guy in gihub conflicting with you :-)
09:05 miconda: cresl1n: all good
09:05 linuxmaniac: miconda: andreas asked me to implement dbonly mode
09:06 linuxmaniac: and I would say is going to be a big change
09:06 miconda: linuxmaniac: do you suggest that next release should be 6.0.0, not 5.0.0?!?!
09:07 linuxmaniac: hahaha
09:07 linuxmaniac: miconda: just asking if there is a sca maintainer
09:08 miconda: linuxmaniac: afaik, the initial developer changed the job, so no official maintainer
09:08 linuxmaniac: ack
09:08 miconda: ok — last call for new topics, otherwise we can end this session
09:09 miconda: it was longer than expected, but with very good outcome to move forward towards 5.0
09:09 miconda: especially for sync’ing — the last summer was rather chaotic for me, a lot of events in the family that I had to attend and required traveling
09:10 qxork: excited about the release
09:10 qxork: any thoughts on dates for Kamailio World?
09:10 linuxmaniac: miconda: great work, thank you
09:10 miconda: qxork: I hope to have the dates before end of November
09:11 miconda: targeting same timeframe, April-May
09:11 qxork: =-)
09:11 qxork: thank you for the great work!
09:11 miconda: I am waiting to see availabitly of the conferencing room
09:11 miconda: Fokus has its own one in rennovation
09:11 miconda: and they had another conference last week, all being too busy to follow my requests
09:12 qxork: Maybe we increase attendance (slightly) and move to Olympiastadion
09:12 miconda: :-)
09:13 miconda: if not hing available at a convenient time in Berlin, it will be in Germany anyhow
09:13 qxork: joran was pushing hard for their locale
09:13 qxork: Yeni doesn't care as long as she travels to Europe
09:13 miconda: it’s indeed an option, but I am also constrained by the co-organized
09:14 miconda: … co-organizers
09:14 miconda: qxork: we will get you to berlin, anyhow
09:14 miconda: it’s a must visit place for kamailio :-)
09:15 linuxmaniac: Alicante is a must place for kamailio :-P
09:15 miconda: ok … so the devel meeting session is ended — as a marker for minutes

Keys	Action
`?`	Open this help
`n`	Next page
`p`	Previous page
`s`	Search