@mshary: commenting on your statement:

On the python side, my example just shows that whatever we pass as argument (whether $fU or KSR.kx.get_fuser() or "any-string-value"), the module function will accept and take care of it (i.e. fetch the actual string value internally), this is already tested in my lab environment.

The issue is you try to leverage variables specific for kamailio.cfg-language inside another programming language, going via kamailio.cfg fixup-mechanism, which is usually done only at startup to optimize for runtime and many of them allocate memory, which has to be freed every time if used repeatedly.

It is also some performance penalty to parse every time the parameter for kamailio.cfg variables, evaluate them, build the evaluated parameter value, use it and the free. Case by case, this could be desired, but it should not be the common approach.

Further more, some scripting languages use similar notation with $name for variables, like Ruby, and the functions exported by KEMI must to conflict with them -- like in the next basic example (taken from the internet, not showing a kemi function, but trying to make the point):

#!/usr/bin/ruby

$ru = 10
class Class1
   def print_global
      puts "Global variable in Class1 is #$ru"
   end
end

Hoping that makes more sense what I tried to explain.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.