• 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 659 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