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:

• 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

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

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

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

MI_XMLRPC_NG module

• the old MI_XMLRPC_NG module has been renamed to MI_XMLRPC - in order to migrate, you need to update your script and replace mi_xmlrpc_ng references to mi_xmlrpc.

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

• the db_mode parameter has been dropped in favor of the https://opensips.org/docs/modules/3.6.x/usrloc.html#param_working_mode_preset working_mode_preset parameter.
• the shared_pinging parameter has been completely dropped - use the https://opensips.org/docs/modules/3.6.x/usrloc.html#param_pinging_mode pinging_mode parameter.

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

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.

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

• 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

• 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

PRESENCE module

• the refreshWatchers MI function has been completely dropped in favor of the refresh_watchers MI command.

USRLOC module

• the db_mode parameter has been dropped in favor of the https://opensips.org/docs/modules/3.6.x/usrloc.html#param_working_mode_preset working_mode_preset] parameter.
• the shared_pinging parameter has been completely dropped - use the https://opensips.org/docs/modules/3.6.x/usrloc.html#param_pinging_mode pinging_mode] parameter.

RabbitMQ module

• the rabbitmq module has been completely merged into the event_rabbitmq module. In order to migrate, you need to remove the loadmodule "rabbitmq.so" line and add the loadmoule "event_rabbitmq.so" line, in case it was not previously loaded.

Registrar module

• for the attr_avp, the behavior is changed: it is still read from AVPs at save() time, but the contact attributes are now pushed back (at lookup() time) into message branch attributes $msg.branch.attr() - see example here.

Event_route module

• the event_route module has been completely dropped and merged into core. Thus, you no longer need to load the module in your script, as it will be automatically loaded at startup. In order to migrate, simply delete the loadmodule "event_route.so" line from your script.

RabbitMQ module

• the rabbitmq module has been completely merged into the event_rabbitmq module. In order to migrate, you need to remove the loadmodule "rabbitmq.so" line and add the loadmoule "event_rabbitmq.so" line, in case it was not previously loaded.

(:toc-back Back to Table of Contents:)

Subscriber table

Table migration

Subscriber

• email_address and rpid columns have been completely dropped from the subscriber table = if you want to preserve the columns in your setup, you need to manually add them to the new migrated table and copy the values from the old one.

• On Debian and Fedora/Redhat, the opensips-berkeley-module, opensips-mysql-module, opensips-postgres-module and opensips-sqlite-module packages no longer come with the associated database schemas for each backend - instead, four new packages are being built, namely opensips-berkeley-dbschema, opensips-mysql-dbschema, opensips-postgres-dbschema and opensips-sqlite-dbschema, which contain the corresponding database schema for each backend. Since there is no cross dependency between the module and the dbschema, if one needs the schema as well, it needs to be installed the dbschema package separately. This change is being done on purpose, to be able to install the dbschema files on separate machines, and use them separately to install (for example using opensips-cli).

• On Debian and Fedora/Redhat, the opensips-berkeley-module, opensips-mysql-module, opensips-postgres-module and opensips-sqlite-module packages no longer come with the associated database schemas for each backend - instead, four new packages are being built, namely opensips-berkeley-dbschema, opensips-mysql-dbschema, opensips-postgres-dbschema and opensips-sqlite-dbschema, which contain the corresponding database schema for each backend. Since there is no cross dependency between the module and the dbschema, if one needs the schema as well, it needs to be installed the dbschema package separately. This change is being done on purpose, to be able to install the dbschema files on separate machines, and use them separately to install (for example using opensips-cli).

SIPREC module

• the media_ip parameter in the $siprec has been dropped, being fully replaced with the media parameter.

• paramameter script_route_avp_result has been dropped, and its behavior has been replaced with the newly added return values. Check the script_route documentation for more information.

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

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

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

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

   # opensips-cli -x database migrate 3.5_to_3.6 opensips_3_5 opensips_3_6

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

Core Variables

• example

Core MI commands

• example

Prometheus module

• paramameter script_route_avp_result has been dropped, and its behavior has been replaced with the newly added return values. Check the script_route documentation for more information.

• consider using the new set_via_handling() instead of force_rport(), add_local_report() or force_tcp_alias() (which are to be deprecated in the future)

This module does not exist anymore. All its functions were re-distributed and replaced as follows:

• avp_db_load/store/delete() functions were moved and renamed as sql_avp_load/store_delete() in the sqlops module
• avp_db_query() function was moved and renamed as sql_query() in the sqlops module
• avp_remove() function was removed, as it can be replaced with scripting $avp(x):=NULL
• avp_pushto() function was removed, as it can be replaced with scripting assignment operation
• avp_check() function was removed, as it can be replaced with scripting testing operators
• avp_copy() function was removed, as it can be replaced with scripting assignment operation
• avp_subst() function was removed, as it can be replaced with scripting {re.subst} transformation
• avp_op() function was removed, as it can be replaced with scripting operations
• is_avp_set() function was removed, as it can be replaced with scripting if ($avp(x)==NULL) {}
• avp_shuffle() function was moved under the shuffle_avps() name into the cfgutils module
• avp_print() function was moved to the OpenSIPS core under the same name

• BE CAREFUL, the DOUBLE types are now returned as strings, rather than corrupted numerical values.

• none

• consider using the new set_via_handling instead of force_rport(), add_local_report() or force_tcp_alias() (which are to be deprecated in the future)

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

• BE CAREFUL, the DOUBLE types are now returned as strings, rather than corrupted numerical values.

CACHEDB_LOCAL module

• added cache_fetch_chunk("keyprefix*", collection) MI function

AVPOPS module

• renamed into DBops module

SQL_CACHER module

• the DOUBLE types are now returned as strings, rather than corrupted numerical values.

• The mpath parameter can take several values. This means that if your script contains several declarations, and you rely on the fact that only the last one is being used, you need to completely delete (or comment) the previous ones, otherwise they will be taken into account in the modules search algorithm, and moreover, they will be prioritized.

Documentation -> Migration -> Migration from 3.4.x to 3.5.0

This section is meant to provide useful help in migrating your OpenSIPS installations from the 3.4.0 version to 3.5.0.

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

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

   # opensips-cli -x database migrate 3.4_to_3.5 opensips_3_4 opensips_3_5

• opensips_3_4 is the existing DB name corresponding to version 3.4.x format
• opensips_3_5 is the DB name to be created for 3.5.x format

Core Variables

• example

Statistics migration

• example

• log_facility has been deprecated and replaced with syslog_facility.
• log_name has been deprecated and replaced with syslog_name.
• log_stderror has been deprecated and is now equivalent with setting the new stderror_enabled and syslog_enabled parameters as following:
  • log_stderror=yes - stderror_enabled=yes and syslog_enabled=no (default)
  • log_stderror=no - stderror_enabled=no and syslog_enabled=yes.

• NEW package available in the repos: opensips-auth-modules, containing both the auth and uac_auth modules, mainly due to their extra dependency on a TLS library to be present on the system (e.g. OpenSSL or WolfSSL)

• NEW package available in the repos: opensips-auth-modules, containing both the auth and uac_auth modules, mainly due to their extra dependency on a TLS library to be present on the system (e.g. OpenSSL or WolfSSL)

• NEW package available in the repos: opensips-auth-modules, containing both the auth and uac_auth modules, mainly due to their extra dependency on a TLS library (e.g. OpenSSL or WolfSSL)

• Check the module docs for the flags parameter of the t_relay() function for the mapping between the old and new flag names.

Packaging migration

AUTH modules

• the auth and uac_auth module are now part of a new package, opensips-auth-modules, mainly due to their extra dependency on a TLS library (e.g. OpenSSL or WolfSSL)

• The $DLG_flags variable now returns a list of flag names separted by space instead of a single integer value.

MID_REGISTRAR module

• Check the module docs for the flags parameters of the mid_registrar_save() and mid_registrar_lookup() functions for the mapping between the old and new flag names.

NATHELPER module

• Check the module docs for the flags parameters of the fix_nated_sdp() and nat_uac_test() functions for the mapping between the old and new flag names.

REGISTRAR module

• Check the module docs for the flags parameters of the save() and lookup() functions for the mapping between the old and new flag names.

TM module

• Check the module docs for the flags parameter of the t_relay() function for the mapping between the old and new flag names.

• The $DLG_flags variable now returns a list of flag names separted by space instead of a single integer value.

• The val parameter of store_dlg_value() is now a variable.
• the first parameter, idx of the set_dlg_flag(), test_and_set_dlg_flag(), reset_dlg_flag(), is_dlg_flag_set() functions is now a static string.
• The $DLG_flags variable now returns a list of flag names separted by space instead of a single integer value).

• example

DIALOG module

• The val parameter of store_dlg_value() is now a variable.

• The flags of the b2b_bridge() function have been renamed as following:

• The flags of the b2b_init_request() function have been renamed as following:

• The init_sdp_body and init_sdp_ctype parameters of the b2b_init_request() function have been dropped.
• The use_init_sdp module parameter has been dropped.

B2B_LOGIC module

• The flags of the b2b_bridge_retry() function have been renamed as following:
  • n to notify
  • f to rollback-failed
  • t[nn] to max_duration=[int].
• The flags of the b2b_bridge_retry() function have been renamed as following:
  • a to transparent-auth
  • p to preserve-to
  • t[nn] to setup-timeout=[nn]

CFGUTILS module

• the 'ts_usec_delta()' 5th parameter has changed

• the output of the list_blacklists rules have changed to improve readability:

• the output of the https://www.opensips.org/Documentation/Interface-CoreMI-3-4#list_blacklists rules have changed to improve readability:
  • owner - now a string
  • expire - indicates the number of seconds until the rule expires
  • proto - printed as string protocol, or "any"

Documentation -> Migration -> Migration from 3.3.x to 3.4.0

This page has been visited 479 times. (:toc-float Table of Contents:)

This section is meant to provide useful help in migrating your OpenSIPS installations from the 3.3.0 version to 3.4.0.

You can find the all the new additions in the 3.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!

DB migration

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

   # opensips-cli -x database migrate 3.3_to_3.4 opensips_3_3 opensips_3_4

where :

• opensips_3_3 is the existing DB name corresponding to version 3.3.x format
• opensips_3_4 is the DB name to be created for 3.4.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

(:toc-back Back to Table of Contents:)

Script migration

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

• example

Global Parameters

• example

Core Variables

• example

Core keywords

• example

Core functions

• example

Core MI commands

• example

Statistics migration

• example

Module migration

CGRateS module

• example