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

This page has been visited 1056 times.

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.

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.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

where :

• 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

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  Subscriber table

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

Back to Table of Contents

2.  Script migration

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

• none

3.  Module migration

3.1  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.

3.2  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.

3.3  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.

3.4  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.

3.5  SIPREC module

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

4.  Deprecated functions / parameters

The following functions / parameters are marked as deprecated - they still work 100% as before, but they will be removed in the future releases, being replaced by new functions / parameters.

So heads up and consider replacing them in time:

4.1  Core

• $bf, to be replaced by $msg.branch.flags
• $branch, to be replaced by $msg.branch
• $branch.fields, to be replaced by $msg.branch.uri
• $branch.flag, to be replaced by $msg.branch.flag()
• append_branch(), to be replaced by append_msg_branch()

4.2  Modules

• TM variable $T_branch_last_reply_code to be replaced by $tm.branch.last_received

5.  Packaging migration

• 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).