Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
install:3.0.x-to-3.1.x [2010/10/04 10:06] miconda |
install:3.0.x-to-3.1.x [2010/10/11 20:05] (current) 87.93.206.26 |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Upgrade from 3.0.x to 3.1.x ====== | ====== Upgrade from 3.0.x to 3.1.x ====== | ||
| - | |||
| - | Note: 3.1.x has not been released it, target date is September 2010. Until then, 3.1.x means GIT master branch (development version). | ||
| 3.0.x refers to Kamailio releases 3.0.x and SR branch sr_3.0. | 3.0.x refers to Kamailio releases 3.0.x and SR branch sr_3.0. | ||
| Line 42: | Line 40: | ||
| </ | </ | ||
| - | Next is the MySQL script to update tables for lcr module. **Beware** that you will lose old data you had for lcr module since the new version requires new tables, therefore old tables are removed. | + | ==== lcr tables ==== |
| + | |||
| + | You can migrate from old data and db structure of lcr module to new version by using migration script available at: | ||
| + | * http:// | ||
| + | |||
| + | If you want to do by hand or you don't have any data in lcr module tables, then next is the MySQL script to update tables for lcr module. **Beware** that by running the script as provided next, you will lose old data you had for lcr module since the new version requires new tables, therefore old tables are removed. | ||
| <code c> | <code c> | ||
| Line 103: | Line 106: | ||
| * http:// | * http:// | ||
| - | ==== modules_k/ | ||
| - | * a new column in address table to hold a tag value per record. The value is returned in peer tag avp upon address matching. | + | ==== modules_k/ |
| - | ==== modules/tm ==== | + | * Module is now using modules/auth api. |
| + | * Functions radius_www_authorize()/ | ||
| + | * Realm argument must now be always given when radius_www_authorize()/ | ||
| + | * See http:// | ||
| - | * no timer parameters value adjustments - they are milisecond, therefore make sure the values of **fr_inv_timer**, | + | ==== modules_k/ |
| - | * new parameter **failure_reply_mode** to control winning branch selection (reply code) for failure_route - if you used kamailio config, be sure you set this parameter to **3** in order to have same behavior as in 1.5.x or lower and 3.0.x. Otherwise, see t_drop_replies() function to control the behaviour per transaction inside config file, within failure_route. | + | |
| + | * If configuration parameter " | ||
| + | * New callback type DLGCB_SPIRALED will be executed on detection of a spiraling message (" | ||
| + | * Changes to database: toroute column was removed, toroute_name column was added | ||
| + | |||
| + | ==== modules_k/ | ||
| + | |||
| + | * Changes to database: attrs column was added | ||
| ==== modules/lcr ==== | ==== modules/lcr ==== | ||
| Line 122: | Line 133: | ||
| * If gateway IP address is NULL, all test functions fail on that LCR instance, because for performance reasons, DNS queries are not done and test functions operate only on IP addresses. | * If gateway IP address is NULL, all test functions fail on that LCR instance, because for performance reasons, DNS queries are not done and test functions operate only on IP addresses. | ||
| * MI functions are not supported anymore; use RPC functions instead. | * MI functions are not supported anymore; use RPC functions instead. | ||
| - | |||
| - | ==== modules_k/ | ||
| - | |||
| - | * Module is now using modules_s/ | ||
| - | * Functions www_challenge()/ | ||
| - | * Functions radius_www_authorize()/ | ||
| - | * Realm argument must now be always given when radius_www_authorize()/ | ||
| - | * See modules_s/ | ||
| - | |||
| - | ==== modules_k/ | ||
| - | |||
| - | * rl_drop() was dropped (same functionality can be achieved with: append_to_reply() and sl_send_reply() - see the README file. | ||
| ==== modules_k/ | ==== modules_k/ | ||
| Line 139: | Line 138: | ||
| * rtpproxy functionality was removed from the nathelper module and belongs to the new rtpproxy module - see README files for both modules. | * rtpproxy functionality was removed from the nathelper module and belongs to the new rtpproxy module - see README files for both modules. | ||
| - | ==== modules_k/dialog | + | ==== modules_k/permissions |
| - | * If configuration parameter " | + | * a new column in address table to hold a tag value per record. The value is returned in peer tag avp upon address matching. |
| - | * New callback type DLGCB_SPIRALED will be executed on detection of a spiraling message (" | + | |
| + | ==== modules_k/ | ||
| + | |||
| + | * rl_drop() was dropped (same functionality can be achieved with: append_to_reply() | ||
| + | * module moved to modules/ | ||
| ==== modules_k/ | ==== modules_k/ | ||
| Line 152: | Line 155: | ||
| * module was merged in **modules/ | * module was merged in **modules/ | ||
| + | ==== modules/tm ==== | ||
| + | |||
| + | **IMPORTANT - pay attention to next changes** | ||
| + | |||
| + | * removed the auto-adjustment of timer parameters for too low values (in Kamailio 3.0.x, if the value was lower than 120, they were multiplied with 1000) | ||
| + | * all timer parameters must be set in milisecond | ||
| + | * make sure the values of **fr_inv_timer**, | ||
| + | * note that dynamic timeout values given via avps for each transaction are still in seconds | ||
| + | * you can use t_set_fr(...) functions with milisecond parameters as alternative to avps. | ||
| + | * new parameter **failure_reply_mode** to control winning branch selection (reply code) for failure_route | ||
| + | * if you used kamailio config, be sure you set this parameter to **3** in order to have same behavior as in 1.5.x or lower and 3.0.x | ||
| + | * otherwise, see t_drop_replies() function to control the behaviour per transaction inside config file, within failure_route. | ||
| ===== Core ===== | ===== Core ===== | ||
| - | * no effect of config compat mode in core - drop() action is the same all the time | + | * no more different behaviour based on config compat mode in core |
| - | * drop a reply in onreply route | + | * drop() action is the same all the time |
| - | * drop the request in onsend route | + | * drop a reply in onreply route |
| + | * drop the request in onsend route | ||
