From openSIPS

Documentation: Migration-3-6-0-to-4-0-0

Documentation -> Migration -> Migration from 3.6.x to 5.0.x

This page has been visited 504 times.

This section is meant to provide useful help in migrating your OpenSIPS installations from the 3.6.x version to 4.0.x.

You can find the all the new additions in the 4.0 release compiled under this page. The ChangeLog may help your understanding of the migration / update process.

Make sure you don't carry a left-over Makefile.conf file in your OpenSIPS source tree if migrating to a new branch! This configuration file, generated by make menuconfig, is usually not compatible with the one of a previous major release!

1.  DB migration

You can migrate your 3.6.x MySQL DB to the 4.0.x format using the opensips-cli tool :

   # opensips-cli -x database migrate 3.6_to_4.0 opensips_3_6 opensips_4_0

where :

• opensips_3_6 is the existing DB name corresponding to version 3.6.x format
• opensips_4_0 is the DB name to be created for 4.0.x format

See the opensips-cli documentation for more details.

NOTE:

• the old database will not be deleted, altered or changed - it will not be touched at all
• new database will be created and data from old DB will be imported into it

1.1  MI naming logic

• Canonical format: all MI commands are exported as module:command.
• Legacy names: old MI names are kept as aliases where available.
• Unqualified call: calling only command works only if the name is unambiguous.
• Ambiguous call: ambiguous unqualified calls fail with JSON-RPC code -32001 (Method ambiguous).
• Alias limit: each MI command can define up to 4 aliases.
• Group listing: which command=module: lists all commands from that module/group.

The following table summarizes all MI function migration changes:

2.  Script migration

The following is the full list of backwards-incompatible syntax or functional changes in the OpenSIPS configuration script:

• none

Global Parameters

• The log_stderror parameter has been completely dropped, use stderror_enabled and/or instead
• The log_facility parameter has been completely dropped, use syslog_facility instead
• The log_name parameter has been completely dropped, use syslog_name instead
• The listen parameter has been completely dropped, use socket instead

Core Variables

• example

Core keywords

• example

Core functions

• example

Core MI commands

• Canonical MI command format is now module:command (for example, usrloc:rm_contact, blacklists:list).
• Local (module-less) MI calls are still accepted only if the local name is unambiguous across all modules.
• Ambiguous module-less MI calls now fail with JSON-RPC custom error code -32001 (Method ambiguous) and return the supported canonical names.
• MI commands can define up to 4 aliases (typically old names kept for compatibility).
• Core command regrouping:
  • mem_* -> mem:*
  • sr_* -> status_report:* (with sr_get_status -> status_report:get)
  • event MI commands -> evi:*
  • cache MI commands -> cache:*
• The which MI command now supports module listing by suffixing the module with : (example: which command=dialog: lists all dialog MI commands).

Statistics migration

• example

3.  Module migration

• All MI function renames are consolidated in the MI command migration table above.

DIALOG module

• Full rework of create_dialog()'s flag arguments, now using hyphenated, full flag names instead of single-letter names for better script readability. Make sure to update your previous flags to their 4.0 counterparts.

MI_XMLRPC_NG module

• The old MI_XMLRPC_NG module has been renamed to MI_XMLRPC - in order to migrate, replace mi_xmlrpc_ng references with mi_xmlrpc.

USRLOC module

• The db_mode parameter has been dropped in favor of working_mode_preset.
• The shared_pinging parameter has been completely dropped - use pinging_mode.