Documentation -> Migration -> Migration from 1.4.x to 1.5.x

This page has been visited 6412 times.

---

This section is to provide useful help in migrating your OpenSIPS installations from any release from 1.4 branch to any release from 1.5 branch.

You can find the all the new additions in 1.5.x release compiled under this page. Overviewing it, may help you understanding the migration / update process.

---

1.  DB migration

The database structure was not affected by major changes (like changing the format existing tables). But new tables were added (corresponding to the newly added modules).

The biggest change concerning the DB structure was reworking some datatypes for MYSQL - replacing varchar with char in order to speed up the DB access.

You can migrate your 1.4.x DB to the 1.5.x format by using the opensipdbctl(deprecated) or osipsconsole tools:

   # opensipsdbctl migrate opensips_1_4 opensips_1_5
   or
   # osipsconsole 
   > migrate opensips_1_4 opensips_1_5
   > quit
   # 

where :

• opensips_1_4 is the existing DB name corresponding to version 1.4.x format
• opensips_1_5 is the DB name to be created for 1.5.x format

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

Take care and edit (if necessary) the opensipsctlrc / '''osipsconsolerc" files if you want to customize the DB users used for accessing the new DB.

NOTE that the migration tool is available only for MYSQL databases!

Back to Table of Contents

---

2.  Script migration

2.1  OpenSIPS core

1. "reply_to_via" core parameter was removed.
2. if only stateful forwarding is used, the core will automatically drop the stateless replies (see: http://lists.opensips.org/pipermail/users/2009-February/002951.html)
3. if you were defining "alias" core parameter to define domains that were also set via the domain module just to make record_routing/loose_routing work, you can remove them as the domain module will automatically export the loaded domains to the core as aliases (see http://lists.opensips.org/pipermail/users/2009-February/002869.html)

Back to Table of Contents

---

2.2  Append_branch() usage

There is no need to call "append_branch()" function in failure_route in order to use the RURI - you still need to use it only if you want to do parallel forking.

Ex:
 # in 1.4.x
 failure_route[2]
    if (t_check_status("408")) {
       # set new RURI
       rewritehostport("my_voicemail.com:5060");
       append_branch();
       t_relay();
    }
  }

  -> 
  # in 1.5.x
  failure_route[2]
    if (t_check_status("408")) {
       # set new RURI
       rewritehostport("my_voicemail.com:5060");
       t_relay();
    }
  }

Affected modules (from scripting perspective) are:

• uac_redirect, get_redirects() function
• lcr, next_gw() function
• dispatcher, ds_next_xxxx() functions

After the listed functions, there is no need to call 'append_branch()' any more.

Back to Table of Contents

---

2.3  SIP replies from script

A set of existing module do requires (as module dependency) a newly added module called "signaling".

In other words, if you use one of the following module, you will need to load also the "signaling" module:

• auth
• auth_db
• auth_diameter
• cpl-c
• options
• perl
• presence
• presence_xml
• ratelimit
• registrar
• rls
• sst

Back to Table of Contents

---

2.4  OpenSIPS modules

DB_MYSQL module

1. auto_reconnect module option was dropped (auto-reconnect is by default due prepared statements).

DIALOG module

1. before using the profile functions, it is mandatory to call "create_dialog" function to create the dialog.

TM module

1. "t_release" function is obsoleted - there is no need to use it as the TM will automatically release any pending transactions.

REGISTRAR module

1. "aor_avp" module paramter is obsoleted - the lookup() / save() / registered() functions takes as third optional parameter a pseudo-variable containing a custom AOR value.

AUTH module

1. the return code "STALE_NONCE" will be also reported if nonce reusage case is detected by "www/proxy_authorize()" functions

Back to Table of Contents

---

3.  RADIUS support

All the RADIUS module do require a new RADIUS AVP to be available in the RADIUS dictionary : "Acct-Session-Id"

This AVP should be provided by the radius client lib you are using as it is a standard SIP RADIUS AVP. IF not, add to your dictionary AVP:

   ATTRIBUTE Acct-Session-Id               44  string     # RFC2865, acc

Back to Table of Contents

---

4.  Tools migration

osipsconsole, an interactive console like application will replace opensipsctl and opensipsdbctl - the console offers the save functions as the scripts it replace.

It is indicated to start migrating to osipsconsole asap.

Back to Table of Contents

---