Kamailio SIP Server Wiki

User Tools

Site Tools

Trace:
devel:kamailio-5.0-design

Differences

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

Link to this comparison view

Next revision 		Previous revision
Last revision Both sides next revision
devel:kamailio-5.0-design [2016/02/24 23:20]
miconda created 		devel:kamailio-5.0-design [2016/04/25 23:05]
miconda [Unit Test Framework]
Line 1: Line 1:
 ====== Kamailio v5.0 Design ====== ====== Kamailio v5.0 Design ======
 +
 +===== Overview =====
  
 After 15 years of development, it is time for Kamailio v5.0. After 15 years of development, it is time for Kamailio v5.0.
 +
 +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: Camille Oudout, Daniel-Constantin Mierla, Federico Cabiddu, Giacomo Vacca, Henning Westerholt, Olle E. Johansson, Torrey Searle, Victor Seva.
  
 ===== 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/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 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:
 +
 +<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 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.
 +
 +Available frameworks:
 +
 +  * http://robotframework.org/ (python)
 +
 +==== 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't have missing linking symbols
 +  * can be done with a config as simple as:
 +
 +<code>
 +
 +loadmodule "foo.so"
 +
 +request_route {
 +  ;
 +}
 +</code>
  
 +  * or can require setting some module parameters or even loading other modules
devel/kamailio-5.0-design.txt · Last modified: 2016/05/03 18:33 by miconda

Page Tools

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki