17 Nov
2010
17 Nov
'10
3:18 p.m.
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:
http://asipto.com/u/h
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
17 Nov
17 Nov
3:21 p.m.
Definitely cool!
Thanks,
Carsten
2010/11/17 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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:
http://asipto.com/u/h
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Carsten Bock
Schomburgstr. 80
22767 Hamburg
Germany
Mobile +49 179 2021244
Home +49 40 34927217
Fax +49 40 34927218
mailto:carsten@bock.info
19 Nov
19 Nov
8:27 p.m.
2010/11/17 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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:
http://asipto.com/u/h
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 :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
20 Nov
20 Nov
10:15 a.m.
On 11/19/10 8:27 PM, Iñaki Baz Castillo wrote:
2010/11/17 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
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
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:
http://asipto.com/u/h
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 :)
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Trainings
Nov 22-25, 2010, Berlin, Germany
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
10:24 a.m.
Daniel-Constantin Mierla wrote:
On 11/19/10 8:27 PM, Iñaki Baz Castillo 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?
2010/11/17 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
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 :) 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:
http://asipto.com/u/h
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 :)
10:30 a.m.
On 11/20/10 10:24 AM, Jeremya wrote:
Daniel-Constantin Mierla wrote:
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
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Trainings
Nov 22-25, 2010, Berlin, Germany
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
On 11/19/10 8:27 PM, Iñaki Baz Castillo 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? 2010/11/17 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
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 :) 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:
http://asipto.com/u/h
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 :) 
22 Nov
22 Nov
9:37 a.m.
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
23 Nov
23 Nov
12:37 a.m.
On 11/22/10 9:37 AM, Henning Westerholt wrote:
On Saturday 20 November 2010, Jeremya wrote:
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
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
[..]
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 
20 Nov
20 Nov
10:27 a.m.
El Sat, 20 Nov 2010 10:15:27 +0100
Daniel-Constantin Mierla <miconda(a)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.
10:34 a.m.
On 11/20/10 10:27 AM, Jon Bonilla (Manwe) wrote:
El Sat, 20 Nov 2010 10:15:27 +0100
Daniel-Constantin Mierla<miconda(a)gmail.com> escribió:
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
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Trainings
Nov 22-25, 2010, Berlin, Germany
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
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.
4927
days inactive
4932
days old
9 comments
6 participants
participants (6)
-
Carsten Bock -
Daniel-Constantin Mierla -
Henning Westerholt -
Iñaki Baz Castillo -
Jeremya -
Jon Bonilla