Development -> Planning -> OpenSIPS Script Rework

   fr_timeout = 4

failure_route [call_failure] {...}

...

[@ opensips-3.0.cfg

1. script starts with the core engine configuration section

1. after the core is configured, we have the section dealing with modules

1. last section is meant to exclusively hold routing routes

1. last section is exclusive for routing routes

    mpath = "/usr/lib/x86_64-linux-gnu/opensips/modules"

    log_stderror = no
    log_facility = LOG_LOCAL0

    log_level = 4

    listen = udp:1.1.1.1

core {

    debug = 4
    log_name = "opensips_proxy.log"
    listen = 1.1.1.1
    mpath = "/tmp/test/"

}

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

Community -> PublicMeetings -> 30th of September 2015

Development -> Topics? -> 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

 example

# script starts with the global param section
debug = 4
log_name = "opensips_proxy.log"
listen = 1.1.1.1
mpath = "/tmp/test/"

# after global params we have the section dealing with modules
loadmodule [tm] {
   fr_timer = 4
   timer_partitions = 2
}
loadmodule [avpops] {
   db_url = "mysql://user:passwd@host/database"
   use_domain = 1
}

# last section is exclusively for routing routes
route {...}
failure_route [resume] {...}
local_route {...}

History

This idea was discussed with the community beforehand, during this 2015 IRC meeting.