Hello,
during last days I spent some time to extend the native API exported to Lua. Many more functions exported by core and modules can be called from embedded Lua scripts. Note that you get also access to psedo-variable operations and you can call all functions exported by modules that have no fixup pretty safe, via sr.modf(...), without a need to be exported natively.
I made an easy-to-do tutorial where all the SIP routing logic is implemented in a Lua script (including authentication, accounting, registrar, user location). You can read it at:
Therefore, if the configuration file language is not offering everything you need to route your SIP traffic, look at app_lua module and its API, it is a real option right now. Lua is a small and fast embeddable language, the interpreter is linked to and loaded by Kamailio at statup, therefore the performance penalty is not significant (Lua project site is: http://www.lua.org). It is also popular among other SIP telephony projects.
Any kind of feedback is appreciated!
Cheers, Daniel
Definitely cool!
Thanks, Carsten
2010/11/17 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
during last days I spent some time to extend the native API exported to Lua. Many more functions exported by core and modules can be called from embedded Lua scripts. Note that you get also access to psedo-variable operations and you can call all functions exported by modules that have no fixup pretty safe, via sr.modf(...), without a need to be exported natively.
I made an easy-to-do tutorial where all the SIP routing logic is implemented in a Lua script (including authentication, accounting, registrar, user location). You can read it at:
Therefore, if the configuration file language is not offering everything you need to route your SIP traffic, look at app_lua module and its API, it is a real option right now. Lua is a small and fast embeddable language, the interpreter is linked to and loaded by Kamailio at statup, therefore the performance penalty is not significant (Lua project site is: http://www.lua.org). It is also popular among other SIP telephony projects.
Any kind of feedback is appreciated!
Cheers, Daniel
-- Daniel-Constantin Mierla Kamailio (OpenSER) Advanced Trainings Nov 22-25, 2010, Berlin, Germany Jan 24-26, 2011, Irvine, CA, USA http://www.asipto.com
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2010/11/17 Daniel-Constantin Mierla miconda@gmail.com:
I made an easy-to-do tutorial where all the SIP routing logic is implemented in a Lua script (including authentication, accounting, registrar, user location). You can read it at:
sr.tm.t_check_trans() sr.sl.send_reply(404, "Not here") sr.tm.t_relay() sr.rr.loose_route() [...]
I'd strongly would like that kamailio config file uses namespaced functions as well, as it's an ellegant way to realize of which module each function belongs to. There are more and more modules and new functions, and it's becoming rather difficult to understand a kamailio/SR script with so many functions sharing the same/unique "namespace".
function_name => module.function_name
It's cool, it's easy, it's sexy :)
BTW the article showing the LUA usage is brilliant :)
On 11/19/10 8:27 PM, Iñaki Baz Castillo wrote:
2010/11/17 Daniel-Constantin Mierlamiconda@gmail.com:
I made an easy-to-do tutorial where all the SIP routing logic is implemented in a Lua script (including authentication, accounting, registrar, user location). You can read it at:
sr.tm.t_check_trans() sr.sl.send_reply(404, "Not here") sr.tm.t_relay() sr.rr.loose_route() [...]
I'd strongly would like that kamailio config file uses namespaced functions as well, as it's an ellegant way to realize of which module each function belongs to. There are more and more modules and new functions, and it's becoming rather difficult to understand a kamailio/SR script with so many functions sharing the same/unique "namespace".
function_name => module.function_name
It's cool, it's easy, it's sexy :)
This should not be that complex, there is no function name that has '.' in order to have current conflicts to solve. My concern is related to modules with very long names, but seems that most of such cases do not export lot of functions (e.g., presence_*).
Alternative is to introduce a short id for modules, eg,:
ps => presence rp => rtpproxy
to be used only when module name is too long.
Btw, this option can speed up a bit the startup, as now resolving a function in config means going through all modules and all functions in a row. Knowing the module, then the search will be only within the list of functions exported by that module. Just a side note, not big influence over all, this being done at startup.
Cheers, Daniel
BTW the article showing the LUA usage is brilliant :)
Daniel-Constantin Mierla wrote:
On 11/19/10 8:27 PM, Iñaki Baz Castillo wrote:
2010/11/17 Daniel-Constantin Mierlamiconda@gmail.com:
I made an easy-to-do tutorial where all the SIP routing logic is implemented in a Lua script (including authentication, accounting, registrar, user location). You can read it at:
sr.tm.t_check_trans() sr.sl.send_reply(404, "Not here") sr.tm.t_relay() sr.rr.loose_route() [...]
I'd strongly would like that kamailio config file uses namespaced functions as well, as it's an ellegant way to realize of which module each function belongs to. There are more and more modules and new functions, and it's becoming rather difficult to understand a kamailio/SR script with so many functions sharing the same/unique "namespace".
function_name => module.function_name
It's cool, it's easy, it's sexy :)
This should not be that complex, there is no function name that has '.' in order to have current conflicts to solve. My concern is related to modules with very long names, but seems that most of such cases do not export lot of functions (e.g., presence_*).
Alternative is to introduce a short id for modules, eg,:
ps => presence rp => rtpproxy
to be used only when module name is too long.
Btw, this option can speed up a bit the startup, as now resolving a function in config means going through all modules and all functions in a row. Knowing the module, then the search will be only within the list of functions exported by that module. Just a side note, not big influence over all, this being done at startup.
Cheers, Daniel
BTW the article showing the LUA usage is brilliant :)
As an aside, is there a current index of functions available? i.e. given a function what module is it from and what it does?
On 11/20/10 10:24 AM, Jeremya wrote:
Daniel-Constantin Mierla wrote:
On 11/19/10 8:27 PM, Iñaki Baz Castillo wrote:
2010/11/17 Daniel-Constantin Mierlamiconda@gmail.com:
I made an easy-to-do tutorial where all the SIP routing logic is implemented in a Lua script (including authentication, accounting, registrar, user location). You can read it at:
sr.tm.t_check_trans() sr.sl.send_reply(404, "Not here") sr.tm.t_relay() sr.rr.loose_route() [...]
I'd strongly would like that kamailio config file uses namespaced functions as well, as it's an ellegant way to realize of which module each function belongs to. There are more and more modules and new functions, and it's becoming rather difficult to understand a kamailio/SR script with so many functions sharing the same/unique "namespace".
function_name => module.function_nameIt's cool, it's easy, it's sexy :)
This should not be that complex, there is no function name that has '.' in order to have current conflicts to solve. My concern is related to modules with very long names, but seems that most of such cases do not export lot of functions (e.g., presence_*).
Alternative is to introduce a short id for modules, eg,:
ps => presence rp => rtpproxy
to be used only when module name is too long.
Btw, this option can speed up a bit the startup, as now resolving a function in config means going through all modules and all functions in a row. Knowing the module, then the search will be only within the list of functions exported by that module. Just a side note, not big influence over all, this being done at startup.
Cheers, Daniel
BTW the article showing the LUA usage is brilliant :)
As an aside, is there a current index of functions available? i.e. given a function what module is it from and what it does?
I mentioned it in the tutorial: http://kb.asipto.com/kamailio:usage:k32-lua-routing#references
But should be added also in app_module readme, you have the available API at: http://sip-router.org/wiki/api/lua/devel
Cheers, Daniel
On Saturday 20 November 2010, Jeremya wrote:
[..] As an aside, is there a current index of functions available? i.e. given a function what module is it from and what it does?
Hi Jeremya,
at least for older versions there is such an index, e.g.:
http://www.kamailio.org/dokuwiki/doku.php/modules:1.5.x:index-functions
Cheers,
Henning
On 11/22/10 9:37 AM, Henning Westerholt wrote:
On Saturday 20 November 2010, Jeremya wrote:
[..] As an aside, is there a current index of functions available? i.e. given a function what module is it from and what it does?
Hi Jeremya,
at least for older versions there is such an index, e.g.:
http://www.kamailio.org/dokuwiki/doku.php/modules:1.5.x:index-functions
btw, do you still have that script somewhere? maybe we can update it.
In the context of this thread, I understood the question was about the functions exported to be available natively to Lua API. Anyhow, many of the functions exported by the modules to kamailio config (the list in the link you pointed) can be called safe from Lua via sr.modf(...).
Cheers, Daniel
El Sat, 20 Nov 2010 10:15:27 +0100 Daniel-Constantin Mierla miconda@gmail.com escribió:
This should not be that complex, there is no function name that has '.' in order to have current conflicts to solve. My concern is related to modules with very long names, but seems that most of such cases do not export lot of functions (e.g., presence_*).
Alternative is to introduce a short id for modules, eg,:
ps => presence rp => rtpproxy
Both of them could be used. One short version for expert people and the long, full format for newbies or in didactical examples.
I think this module.function syntax is a good idea.
On 11/20/10 10:27 AM, Jon Bonilla (Manwe) wrote:
El Sat, 20 Nov 2010 10:15:27 +0100 Daniel-Constantin Mierlamiconda@gmail.com escribió:
This should not be that complex, there is no function name that has '.' in order to have current conflicts to solve. My concern is related to modules with very long names, but seems that most of such cases do not export lot of functions (e.g., presence_*).
Alternative is to introduce a short id for modules, eg,:
ps => presence rp => rtpproxy
Both of them could be used. One short version for expert people and the long, full format for newbies or in didactical examples.
On a second thought, just module name should be enough, because will still be the current version for "experts", at least several releases from now on.
Introducing short alias will just complicate things, adding confusion. In the future we can review the concept and added if many people want it.
Also, we encourage people to find nice short names from beginning of development :-) when only the module name can be used.
Cheers, Daniel
-
Carsten Bock -
Daniel-Constantin Mierla -
Henning Westerholt -
Iñaki Baz Castillo -
Jeremya -
Jon Bonilla