User Tools

Site Tools


devel:kamailio-5.0-design

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
devel:kamailio-5.0-design [2016/02/28 11:50]
miconda
devel:kamailio-5.0-design [2016/04/25 23:05]
miconda [Unit Test Framework]
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 interpretersin 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/integer parameters can be provided by embedded interpreters 
 + 
 +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, "OK"
 + 
 +sr_exapi_t mod_exapi[] = { 
 +  { "sr.tm", "reply", {PARAM_INT, PARAM_STR, 0}, t_reply }, 
 +  { 0, 0, {0}, 0} 
 +}; 
 +</code>
  
 ==== 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:
 +
 +<code>
 +# core parameters
 +...
 +
 +# load modules
 +...
 +
 +# modules parameters
 +...
 +
 +routing="native" # default
 +
 +request_route {
 +  ...
 +}
 +...
 +reply_route {
 +  ...
 +}
 +...
 +</code>
 +
 +Example kamailio.cfg for lua interpreter:
 +
 +<code>
 +# core parameters
 +...
 +
 +# load modules
 +...
 +
 +# modules parameters
 +...
 +
 +routing="lua" with "/path/to/script.lua"
 +
 +</code>
 +
 +The script /path/to/script.lua:
 +
 +<code>
 +function request_route()
 +  ...
 +  sr.t_on_branch("my_branch_route");
 +end
 +
 +function reply_route()
 +  ...
 +end
 +
 +function my_branch_route()
 +  ...
 +end
 +...
 +</code>
 +
 +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/branch/branch-failure processing inside tm (along with existing index of the routing block for "native" config case)
 +  * 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:init)
 +    * 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/friendly for its language (e.g., one may prefer request_route(), other requestRoute() and another RequestRoute())
 +    * 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:
 +
 +<code>
 +// event_route[htable:init] 
 +function htable_event_route(evname)
 +  if evname=="init" then
 +     ...
 +  else
 +     ...
 +  end
 +</code>
 ===== 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 'core' folder in the root directory
 +  * b) move all source code files for Kamailio in a new 'src' folder, with further re-organization with subfolders inside 'src'
  
 ===== Build System ===== ===== Build System =====
  
-Revising the build system based on Makefiles.+Goals: 
 + 
 +  * revising the build system based on Makefiles. 
 + 
 +==== Reviewing Alternative Build Systems ====
  
 Alternatives to analyze: Alternatives to analyze:
Line 62: Line 179:
  
 Reviving the exiting unit testing or selecting another framework. Reviving the exiting unit testing or selecting another framework.
 +
 +Available frameworks:
 +
 +  * http://robotframework.org/ (python)
  
 ==== Minimal Unit Tests ==== ==== Minimal Unit Tests ====
devel/kamailio-5.0-design.txt · Last modified: 2016/05/03 18:33 by miconda