[sr-dev] [kamailio/kamailio] KEMI API implementation for carrierroute module (PR #3247)

Daniel-Constantin Mierla notifications at github.com
Fri Sep 30 11:57:17 CEST 2022


The export of the functions to KEMI is done ok via `sr_kemi_t` structure array and `mod_register()`, but the implementation is not the right approach. In the KEMI script (e.g., python, lua, ...) should not be provided parameters with names of kamailio.cfg-variables, but string/int values computed from expressions in that language.

The fixup-free functions are not *required* for the functions exported to kamailio.cfg, because they are executed only once, at start-up, therefore is no risk of a memory leak if fixup-function allocates memory. But if it is called at run time during SIP packets processing, then it leaks memory. That's why `KSR.x.modf()` is considered *unsafe*.

Actually, what you implemented is more like `KSR.x.modf()`, but without using fixup-free.

I am not familiar at all with carrierroute module, but from C language approach, I pushed three commits to give an example of exporting `cr_user_carrier()` to KEMI. Only the last one (1e3f1886ce) is relevant for KEMI exporting, the other two were to prepare (and somehow fix) the kamailio.cfg-exported function and update the docs for it because it also made it more flexible in terms of what is accepted as 3rd parameter -- the commits are: e84c1947b3 and c32ce4d776 .

@lbalaceanu: with the commit e84c1947b3 I tried to fix an improper approach of having a variable name as parameter, before the `fixup_spve_null()` was used, which is for dynamic strings (string that can combine static parts with variable names, like `sip:$rU@$avp(newdomain)`), relying on some hack to access first field expected to be a variable name, but that is not ensured.

There is a dedicated fixup for single variable name (`fixup_pvar_null()`), which is more appropriate in this case. With this change, the parameter can be any writable variable, which includes AVPs, so backward compatibility is ensured. Further restrictions can be added to allow only AVP by checking `((pv_spec_t *)(*param))->type==PVT_AVP` inside `cr_load_user_carrier_fixup()` and similar in the newly exported KEMI function `ki_cr_load_user_carrier()`.

If the changes I made are considered not ok, then they can be reverted, it's no problem for me, I coded to give a practical example and I was too lazy to go via a temporary branch considering it is the right approach to implement functions exported to KEMI.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3247#issuecomment-1263363580
You are receiving this because you are subscribed to this thread.

Message ID: <kamailio/kamailio/pull/3247/c1263363580 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20220930/8c117b18/attachment-0001.htm>


More information about the sr-dev mailing list