This shows you the differences between two versions of the page.
Next revision | Previous revision Next revision Both sides next revision | ||
devel:kamailio-5.0-design [2016/02/24 23:20] miconda created |
devel:kamailio-5.0-design [2016/03/01 09:49] miconda [Routing Logic In Embedded Interpreters Scripting] |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== Kamailio v5.0 Design ====== | ====== Kamailio v5.0 Design ====== | ||
+ | |||
+ | ===== Overview ===== | ||
After 15 years of development, | After 15 years of development, | ||
+ | |||
+ | This page collects suggestions and ideas for major refactoring of various components to make the leap to v5.0. | ||
+ | |||
+ | When adding a remark that needs to be tracked by author, use initials in front of the paragraph. The list of contributors to this document and initials: | ||
+ | |||
+ | * Daniel-Constantin Mierla (dcm) | ||
+ | |||
+ | ===== Initial Remarks ===== | ||
+ | |||
+ | Initial content for this document is listing also ideas popped up during discussions at Fosdem 2016 and Kamailio Development Workshop - among participants: | ||
===== Configuration File ===== | ===== Configuration File ===== | ||
+ | |||
+ | Goals: | ||
+ | |||
+ | * have at least one option of an optimized configuration file interpreter targeting high performance SIP routing deployments | ||
+ | * have at least one option of a more flexible configuration language that allows: | ||
+ | * extended language syntax | ||
+ | * reloading routing rules at runtime | ||
+ | |||
+ | To achieve the above, following sub-sections collects the proposals for configuration file language. | ||
+ | |||
==== 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 15: | 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 ===== | ||
+ | |||
+ | Goals: | ||
+ | |||
+ | * group files per components to be easier to spot their role, especially the core, include files and utilities | ||
+ | |||
+ | ==== Reorganizing Source Files Location ==== | ||
It was discussed in the past: | It was discussed in the past: | ||
* source code files should be relocated to have a better structure for include headers, core files, modules and internal libraries as well as utilities | * source code files should be relocated to have a better structure for include headers, core files, modules and internal libraries as well as utilities | ||
+ | |||
+ | Two models proposed: | ||
+ | |||
+ | * a) only move core files in a new ' | ||
+ | * b) move all source code files for Kamailio in a new ' | ||
===== Build System ===== | ===== Build System ===== | ||
- | Revising | + | Goals: |
+ | |||
+ | * revising | ||
+ | |||
+ | ==== Reviewing Alternative Build Systems ==== | ||
Alternatives to analyze: | Alternatives to analyze: | ||
Line 30: | Line 169: | ||
* cmake | * cmake | ||
+ | ===== Continuous Integration ===== | ||
+ | |||
+ | Goals: | ||
+ | |||
+ | * attempt to make a more consistent and "easy to contribute to" continuous integration eco-system | ||
+ | |||
+ | |||
+ | ==== Unit Test Framework ==== | ||
+ | |||
+ | Reviving the exiting unit testing or selecting another framework. | ||
+ | |||
+ | ==== Minimal Unit Tests ==== | ||
+ | |||
+ | Defining a minimum set of automatic tests that needs to be provided by each module: | ||
+ | |||
+ | * a minimal config for loading the module, to be sure it doesn' | ||
+ | * can be done with a config as simple as: | ||
+ | |||
+ | < | ||
+ | |||
+ | loadmodule " | ||
+ | |||
+ | request_route { | ||
+ | ; | ||
+ | } | ||
+ | </ | ||
+ | * or can require setting some module parameters or even loading other modules |