Upgrade from VoipNow Professional
If you want to upgrade from VoipNow Professional to latest version of VoipNow, we highly recommend to coordinate this upgrade with our Professional Services team. Please open a ticket in the Support Zone.
This upgrade is 100% supported, but due to the massive changes in VoipNow it is a very good idea to get in touch with the Professional Services team first.
Upgrade VoipNow 3.5.0, 3.6.0 or 3.7.0
In VoipNow 4.0.0 and newer versions the email address of VoipNow accounts (Service Provider, Organization, User) should be unique. Before upgrading to the latest version it is required to check the accounts database for duplicate emails. We have made available a script that allows you to detect such accounts before starting the upgrade.
Login to the VoipNow server (single server deployments) or Infrastructure Controller (distributed deployment). Execute the following command:
Run the script by executing the command:
/usr/local/httpsa/php/bin/php --define register_argc_argv=On --define open_basedir=/usr/local/voipnow:/sbin:/tmp:/etc/voipnow:/usr/local/hubphp --define include_path=/usr/local/voipnow/admin/htdocs:/usr/local/hubphp/libs/PEAR:/usr/local/hubphp:/usr/local/hubphp/libs -q detectduplicateemails.php
Found 8 duplicate emails. A csv file with complete information was saved at /tmp/duplicate_emails20151112120024.csv
More information about the offending accounts can be found the file indicated by the output.
Do not forget to delete the file after reviewing it.
Upgrade from VoipNow 3.0.x
We recommend you to check the release notes, as they might contain important notes, such as the ones about deprecating technologies.
In order to upgrade from VoipNow 3.0.x you have to just follow the installation instructions:
Database schema upgrade
The most important inconvenience when upgrading to the latest version is the potential long upgrade time. This is due to the upgrade in the schema of some large tables (such as call_history).
That's the reason why we recommend to schedule the upgrade outside business hours.
Larger SIP packages
Due to the newly introduced ICE support, SIP packages will contain more information (candidates) and therefore will be larger. While this is normal and creates many benefits, it might also create problems with very old equipment that have trouble dealing with SIP packages larger than 1500 bytes. We advise you to test the latest version of VoipNow with your existing trunking channels.
G729 Not Enabled By Default
While G729 is still supported, we disabled it by default because a very small number of customers acquired appropiate licensing for it.
On a side note, VoipNow 3.5.0 comes with modern codecs that provide a better voice quality and smarter bandwidth usage than G729.
API compatibility
There are no incompatible API changes in the new version.
Upgrade from VoipNow Professional 2.5.x
Upgrade from VoipNow Professional 2.5.x to is technically supported, assuming that a valid license is available for VoipNow 3.
Software license
VoipNow 3 is available for existing customers of VoipNow Professional cloud software licensing at no additional cost. VoipNow 3 is not available for existing customers of VoipNow Professional business licensing or legacy VoipNow Professional licensing.
If you upgrade your VoipNow Professional installation to VoipNow 3 and you do not have a valid license key, please order a new VoipNow license.
Account management
The account level management has been reorganized in order to better match the business profile of the customers. Your Administrator account is going to be unchanged, Resellers accounts will be converted to Service Providers, Clients to Organizations and Extensions to Users with a single Extension. Also a limit of one extension per user is enforced on these users. This can be changed after upgrade.
SystemAPI incompatible changes
Due to various improvements, there are many backwards incompatible changes. These are mostly related to the management of the user accounts and authentication/authorization.
The SystemAPI will be phased out in the future and replaced by a management service in UnifiedAPI.
UnifiedAPI for calls control
The old CallAPI requests must be migrated to the UnifiedAPI requests, the new API that will cover in the future all Apps interaction with VoipNow.
Automation platform plug-ins
The former Platform Plug-ins section in Automation has undergone severe changes. Technology plug-ins can now be used to define a cloud instance for a specific technology version. The cloud instance can be upgraded to the newest technology version when the platform gets upgraded on the deployment facility.
Automation deployment email templates
The deployment email templates can now be customized from a centralized location along with all other email templates in Automation. A deployment email template now supports placeholders in which cloud instances introduce their specific information. Any customized email templates will be lost on upgrade and must be updated afterwards accordingly.
SIP Trunking providers compatibility
The SIP proxy inserts the lr parameter into the Record-Route headers using the following form ";lr". In the previous versions, the format was ";lr=on". This was changed in order to improve interoperability with the Microsoft Lync server. If problems are encountered with other devices, the following line in the SIP server configuration may be altered manually:
modparam("rr", "enable_full_lr", 0)
modparam("rr", "enable_full_lr", 1)
SIP TLS support
The SIP proxy component is accepting by default only TLS v1 connections (RFC3261 compliant). To change this setting, the following line should be edited in the SIP server configuration file:
modparam("tls", "tls_method", "TLSv1")
modparam("tls", "tls_method", "SSLv23")
No Asterisk manager interface
There is no Asterisk Manager Interface in the new version. This is a deprecated, old technology that has been removed forever. UnifiedAPI is the way to go.
VoipNow Desktop is deprecated
VoipNow 3 is not compatible with VoipNow Desktop. VoipNow Desktop is a discontinued product.
Devices that Do Not Answer to SIP options
VoipNow is now recording unreachable extensions (those that do not answer to SIP:Options requests). The unreachable status is now considered by the Incoming Call Rules engine in Transfer rules, if "Not registered/Unreachable" option is enabled. Because some SIP devices might not answer to SIP:Options, in order to prevent the Transfer rule to always trigger disable pinging for those extensions.
LiveMonitor is deprecated
We recommend you to monitor VoipNow using your existing infrastructure monitoring software, that can gather probes from all VoipNow nodes.
Upgrade from VoipNow Professional 1.x
Upgrade from VoipNow Professional 1.x is technically supported, assuming that a valid license is available for VoipNow 3.
Include the domain name into the accepted list
If the devices are configured to include host name information into SIP signaling messages, these will be rejected if the host name is not included in the accepted SIP domains list. The setting is available at the Unified Communications → System Preferences → SIP Preferences page from the web user interface.
Add the SIP trunking information
VoipNow is not accepting incoming calls from any IP. You have to configure the information related to the IPs that are allowed to send calls on a specific SIP trunk. You can configure them following the next steps in the web user interface:
- Click the Channels link available in the left navigation panel.
- Choose the desired channel from the list and click on it.
- Click the Edit channel icon and set the allowed networks using the controls next to the Accept calls from IPs/network option.
Check your routing rules
In VoipNow 1.x, the number processing was always performed before call cost interrogation. Moreover, the processing on the Route rules (previously called Transfer rules) was applied after call cost interrogation. If you want to preserve the same behavior, you need to modify the number using the process rules.
Starting with VoipNow 2.x, it is possible to process dialed numbers in outgoing routing rules before and after the call cost is interrogated according to the cost set up for the channels. When you Route a number through a channel (or through the best cost), the call cost is retrieved from the database at that time. The input for the call interrogation procedure is the processed number (the number can be modified using process directives). If you want to further process the number after the cost is interrogated and settled, you can use the basic number processing available in the Route type rules.
Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 4.0 International.