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 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.

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.

• 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:

// export t_reply(200, "OK")
 
sr_exapi_t mod_exapi[] = {
  { "sr.tm", "reply", {PARAM_INT, PARAM_STR, 0}, t_reply },
  { 0, 0, {0}, 0}
};

• writing the routing logic only in a scripting language supported via embedded interpreters
• eventually setting core parameters, loading modules and setting modules' parameters are still done using the kamailio configuration file but all routing blocks should be possible to be written in an embedded language
• routing logic in an embedded language should allow reloading at runtime without kamailio restart

Example kamailio.cfg for native interpreter:

# core parameters
...

# load modules
...

# modules parameters
...

routing="native" # default

request_route {
  ...
}
...
reply_route {
  ...
}
...

Example kamailio.cfg for lua interpreter:

# core parameters
...

# load modules
...

# modules parameters
...

routing="lua" with "/path/to/script.lua"

The script /path/to/script.lua:

function request_route()
  ...
  sr.t_on_branch("my_branch_route");
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/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:

// event_route[htable:init] 
function htable_event_route(evname)
  if evname=="init" then
     ...
  else
     ...
  end

Goals:

• group files per components to be easier to spot their role, especially the core, include files and utilities

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

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'

Goals:

• revising the build system based on Makefiles.

Alternatives to analyze:

• configure
• cmake

Goals:

• attempt to make a more consistent and “easy to contribute to” continuous integration eco-system

Reviving the exiting unit testing or selecting another framework.

Available frameworks:

• http://robotframework.org/ (python)

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:

loadmodule "foo.so"

request_route {
  ;
}

• or can require setting some module parameters or even loading other modules