Development -> Planning -> OpenSIPS Script Rework

Problems to be addressed

There are two types of problems with the current OpenSIPS scripting language, which relate to both its structure and functionality:

• structural issues - the current grammar is too loose; there is no structuring (like a block for global params, for modules or for routes) and mixing definitions of parameters with loading modules may lead to inconsistent or broken results (i.e. define routes and load the module after that; or load a module and only set the mpath afterwards). This kind of problem prevented 2.1 from having its protocol-oriented modules auto-loaded (simply based on listen statements)
• functionality issues - the routing logic (the actual routes) are too welded to the param/module section and in medium/log term they cannot be separated and handled in different ways (outsourcing the routing logic is something to be considered, according to the "New Design"); Also, the script cannot be reloaded at all, and in production systems, doing a restart only because of minor changes into the routing logic can be painful; In terms of programming/development, the script parser can be improved to automatically support variables in all functions, to support integer parameters, or to also use the exporting mechanism to provide the core functions (the core should do its own export with its functions, rather than having them hardcoded in the grammar).

Proposed Solution

Trying to address the above issues, we suggest a new format for the configuration script:

1) a simple re-structuring to solve the problems, but trying to keep a similarity with the actual structure. The grammar will enforce three main sections in the cfg file, in a certain order:

• global parameters section
• modules section
• routes section

 opensips-3.0.cfg

# script starts with the core engine configuration section
core {
    log_level = 4
    log_stderror = no
    log_facility = LOG_LOCAL0
    listen = udp:1.1.1.1
    mpath = "/usr/lib/x86_64-linux-gnu/opensips/modules"
}

# after the core is configured, we have the section dealing with modules
loadmodule [tm] {
   fr_timeout = 4
   timer_partitions = 2
}

loadmodule [avpops] {
   db_url = "mysql://user:passwd@host/database"
   use_domain = 1
}

# last section is meant to exclusively hold routing routes

route {...}
failure_route [call_failure] {...}
local_route {...}
...

History

The problem and its solution have already been discussed together with the community, during this 2015 IRC meeting.