Development

Development.Design-Opensips-Script-Rework History

Hide minor edits - Show changes to markup

December 13, 2018, at 05:09 PM by 109.99.227.30 -
Changed line 1 from:
to:
December 12, 2018, at 06:31 PM by liviu -
Changed line 32 from:
   fr_timer = 4
to:
   fr_timeout = 4
December 12, 2018, at 06:31 PM by liviu -
Changed line 44 from:

failure_route [resume] {...}

to:

failure_route [call_failure] {...}

Added line 46:

...

December 12, 2018, at 06:30 PM by liviu -
Changed line 19 from:

[@ example

to:

[@ opensips-3.0.cfg

December 12, 2018, at 06:30 PM by liviu -
Changed line 21 from:
  1. script starts with the global param section
to:
  1. script starts with the core engine configuration section
Changed line 30 from:
  1. after global params we have the section dealing with modules
to:
  1. after the core is configured, we have the section dealing with modules
December 12, 2018, at 06:29 PM by liviu -
Changed line 41 from:
  1. last section is exclusive for routing routes
to:
  1. last section is meant to exclusively hold routing routes
December 12, 2018, at 06:28 PM by liviu -
Added line 35:
Changed lines 41-42 from:
  1. last section is exclusively for routing routes
to:
  1. last section is exclusive for routing routes
December 12, 2018, at 06:27 PM by liviu -
Changed line 27 from:
    mpath = "/tmp/test/"
to:
    mpath = "/usr/lib/x86_64-linux-gnu/opensips/modules"
December 12, 2018, at 06:26 PM by liviu -
Changed lines 24-25 from:
    log_name = "opensips_proxy.log"
to:
    log_stderror = no
    log_facility = LOG_LOCAL0
December 12, 2018, at 06:25 PM by liviu -
Changed line 23 from:
    debug = 4
to:
    log_level = 4
Changed line 25 from:
    listen = 1.1.1.1
to:
    listen = udp:1.1.1.1
December 12, 2018, at 06:25 PM by liviu -
Changed lines 22-25 from:

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

to:

core {

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

}

December 12, 2018, at 02:06 PM by liviu -
Changed line 45 from:

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

to:

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

December 12, 2018, at 02:05 PM by liviu -
Deleted line 0:
Community -> PublicMeetings -> 30th of September 2015
December 12, 2018, at 02:04 PM by liviu -
Added lines 1-46:
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.


Page last modified on December 13, 2018, at 05:09 PM