This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
devel:kamailio-5.0-design [2016/02/28 11:57] miconda [Build System] |
devel:kamailio-5.0-design [2016/03/01 09:49] miconda [Routing Logic In Embedded Interpreters Scripting] |
||
---|---|---|---|
Line 29: | Line 29: | ||
==== Exporting Functions To Embedded Interpreters ==== | ==== Exporting Functions To Embedded Interpreters ==== | ||
- | * define and implement an export interface from modules to embedded interpreters to automatically add new functions to embedded interpreters, in a similar fashion as for adding functions to configuration file | + | * define and implement an export interface from modules to embedded interpreters to automatically add new functions to embedded interpreters |
+ | * it should be in a similar fashion as for adding functions to configuration file, but without fixup mechanism, so bare string/ | ||
+ | |||
+ | Interface fields: | ||
+ | |||
+ | * submodule name in embedded interpreter | ||
+ | * function name in embedded interpreter | ||
+ | * parameter types | ||
+ | * pointer to c function | ||
+ | |||
+ | Example: | ||
+ | |||
+ | <code c> | ||
+ | // export t_reply(200, | ||
+ | |||
+ | sr_exapi_t mod_exapi[] = { | ||
+ | { " | ||
+ | { 0, 0, {0}, 0} | ||
+ | }; | ||
+ | </ | ||
==== Routing Logic In Embedded Interpreters Scripting ==== | ==== Routing Logic In Embedded Interpreters Scripting ==== | ||
Line 37: | Line 56: | ||
* routing logic in an embedded language should allow reloading at runtime without kamailio restart | * routing logic in an embedded language should allow reloading at runtime without kamailio restart | ||
+ | === Implementation Ideas === | ||
+ | |||
+ | |||
+ | Example kamailio.cfg for native interpreter: | ||
+ | |||
+ | < | ||
+ | # core parameters | ||
+ | ... | ||
+ | |||
+ | # load modules | ||
+ | ... | ||
+ | |||
+ | # modules parameters | ||
+ | ... | ||
+ | |||
+ | routing=" | ||
+ | |||
+ | request_route { | ||
+ | ... | ||
+ | } | ||
+ | ... | ||
+ | reply_route { | ||
+ | ... | ||
+ | } | ||
+ | ... | ||
+ | </ | ||
+ | |||
+ | Example kamailio.cfg for lua interpreter: | ||
+ | |||
+ | < | ||
+ | # core parameters | ||
+ | ... | ||
+ | |||
+ | # load modules | ||
+ | ... | ||
+ | |||
+ | # modules parameters | ||
+ | ... | ||
+ | |||
+ | routing=" | ||
+ | |||
+ | </ | ||
+ | |||
+ | The script / | ||
+ | |||
+ | < | ||
+ | function request_route() | ||
+ | ... | ||
+ | sr.t_on_branch(" | ||
+ | end | ||
+ | |||
+ | function reply_route() | ||
+ | ... | ||
+ | end | ||
+ | |||
+ | function my_branch_route() | ||
+ | ... | ||
+ | end | ||
+ | ... | ||
+ | </ | ||
+ | |||
+ | Expected changes: | ||
+ | * each module that offers an interpreter for config will advertise a special structure with functions to be executed on various events (e.g., request received, reply received, etc...) | ||
+ | * keep the name of routing blocks for failure/ | ||
+ | * define the function names for routing blocks that are executed automatically | ||
+ | * such as: | ||
+ | * request_route | ||
+ | * reply_route | ||
+ | * onsend_route | ||
+ | * various event_route blocks (e.g., htable: | ||
+ | * eventually there can be a mapping of names used inside kamailio native config and functions inside the embedded interpreter that is inside each module, so each can have a naming pattern more suitable/ | ||
+ | * for event routes executed automatically (not the one armed for tm branch failure which sets the name at runtime), the pattern can be: | ||
+ | * modname_event_route(eventname) -- for example: | ||
+ | |||
+ | < | ||
+ | // event_route[htable: | ||
+ | function htable_event_route(evname) | ||
+ | if evname==" | ||
+ | ... | ||
+ | else | ||
+ | ... | ||
+ | end | ||
+ | </ | ||
===== Source Tree Structure ===== | ===== Source Tree Structure ===== | ||