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

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

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?

• 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 someting 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 someting 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 requiest 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 pictre 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 kamailo 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 memroy
• 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:
• 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 lokup 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 someting 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?
• 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,
• 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
• 09:15 miconda: ok … so the devel meeting session is ended — as a marker for minutes