April 16, 2019
eZuce is pleased to announce the Beta Release of sipXcom 19.04.
As a beta release, some of these notes may be revised before the actual release.
Important - For Beta Testers - Do not directly upgrade to 19.04 from any version before 18.04. The 18.04 upgrade must be completed first. Please read the release notes for 18.04 if you are not on 18.04 yet.
There again will be 2 releases for 19.04. A CentOS 7 release (19.04.centos7) will follow shortly. While it’s a small update, there are a few interesting things to point out.
When a user is deleted from the system, the configuration services will now go through all phones and remove that user from the phones and re-send phone profiles. If that was the only user on the phone, the phone will go back to the auto-provision ID. What we were finding is that administrators were deleting users but not re-sending phone profiles which would then create traffic floods with bad subscribes to MWI and such to the server.
The new Polycom VVX ‘50’ series phones is now supported for configuration as well as auto provision! Firmware 3.8.0 and later supported.
Also, mongoDB has been updated to 3.6.9. This has had a positive effect in recovery from a node outage. The new mongodb seems much more resilient.
This will be the last release for CentOS 6. As of version 19.08 we will only be releasing for CentOS 7! To go from a CentOS 6 based system to a CentOS 7 based system will require a backup and restore. As such a parallel install will be recommended.
Support for Polycom VVX 150, 250, 350 and 450
Alarm for Certificate Expiration
Make mongoDB cache size configurable
Remove user from phones automatically after user deleted from system
Automatically generate certificate from Let’s Encrypt.
Sort alarms alphabetically
Upgrade mongodb to 3.6.9
Add http provisioning option to DHCP configuration
Full Beta Release Notes with installation information are located here: 18.12 Full Beta Release Notes
The regular release of 19.04 will have the ability to upgrade from earlier versions using the upgrade script used in 18.04. For the purposes of this beta release, please only do upgrades from 18.04 if you test systems are on a version earlier than 18.04, upgrade to 18.04 first.
This is a beta release and not recommended for production use.
This release is recommended for all 4.6 and later installations. If you have a patch installed to your system a new patch may be required. Please contact firstname.lastname@example.org if think you may have a patch applied as that may be replaced during the update.
eZuce's software products continuously progress through an Agile based development methodology that keeps feature functionality comprehensive and up-to-date in response to evolving market and customer requirements.
New software releases are made at a rate of two to four releases a year. Releases are numbered in the <yy>.<mm>.<uu> format where <yy> and <mm> designate the year and the month, respectively, in which a release is made generally available. Where applicable, <uu> corresponds to an update release relative to a general release on which fixes are made available.
In order to ensure service continuity and stability, customers may keep their production environments unchanged for up to a 6-month period during which release updates or patches are made available. After a release is more than 6-months old, eZuce customers would have to upgrade to the latest generally available release - inclusive of all fixes to date and any new patches.
If you have questions about updating you can email email@example.com.
We're currently running on a 4-month release cycle.
Release Level History
For a reasonably performing system, we recommend the following configuration.
CentOS/RHEL 6 x86_64 with latest updates is required.
Technical Reference Manuals, User Guides, Reach Reference Manuals, and other technical and user information can be found under the following link: Documentation Page
Please be aware of these Mongodb requirements http://docs.mongodb.org/manual/reference/ulimit/ Note: Both the “hard” and the “soft” ulimit affect MongoDB’s performance. The “hard” ulimit refers to the maximum number of processes that a user can have active at any time. This is the ceiling: no non-root process can increase the “hard” ulimit. In contrast, the “soft” ulimit is the limit that is actually enforced for a session or process, but any process can increase it up to “hard” ulimit maximum.Every deployment may have unique requirements and settings; however, the following thresholds and settings are particularly important for mongod and mongos deployments:
ulimit –a -f (file size): unlimited -t (cpu time): unlimited -v (virtual memory): unlimited -n (open files): 64000 -m (memory size): unlimited -u (processes/threads): 32000
Always remember to restart your mongod and mongos instances after changing the ulimit settings to make sure that the settings change takes effect.If you limit virtual or resident memory size on a system running MongoDB the operating system will refuse to honor additional allocation requests. After every install/upgrade please check that "cat /proc/$pid_of_mongo/limits" have the recommended value of 655350. To make this value permanent you need to create this file /etc/security/limits.d/99-mongodb-nproc.conf and add the following lines:
mongodb soft nproc 64000
mongodb hard nproc 64000
mongodb soft nofile 64000
mongodb hard nofile 64000
If you have a patch installed to your system a new patch may be required. Please contact firstname.lastname@example.org if think you may have a patch applied as that may be replaced during the update.
Beta version has no ISO, must use RPM Installation!
Download the ISO image corresponding to your hardware and write the image to a DVD.
sipXcom can be installed using the following procedure
yum update && reboot
curl https://download.ezuce.com/openuc-setup > /usr/bin/openuc-setup chmod +x /usr/bin/openuc-setup openuc-setup
This utility will guide you through the process of installing uniteme from the eZuce software repository.
Special Note: For Beta testers, please modify your baseurl to be:
We will be utilizing an upgrade script to ensure upgrades proceed as intended and so that customers have the appropriate warnings and information before upgrading.
Make sure you backup your system (configuration and voicemail at a minimum) prior to installation. You'll be upgrading mongodb to a new version!
Login to the Admin GUI and click on System -> Backup and at a minimum backup configuration and voicemail.
Do it now... before you go any further.
Login to the primary server as root.
Execute the following:
chmod +x upgrade.sh
Execute the upgrade script and answer 'Yes' to continue:
The following will be displayed:
Uniteme 18.12 Upgrade Script
IMPORTANT: If this is a multi-server cluster, all databases except the Primary (which must be on the configuration server) should be removed.
IMPORTANT: You should run a system backup and copy your config and voicemail backups to another system. If the upgrade fails, you will need to build a new server and restore from backup.
IMPORTANT: Ensure that you have enough disk space available for a copy of the Mongo databases. (roughly your Config + Voicemail backups).
IMPORTANT: 18.08 does not have Reachme in it, if you use Reachme on this server or in the cluster, do not continue!
This script will do the following:
- Back up mongo config and dbs
- Stop mongo instance and remove old mongo files
- Change 17.10 occurrences in /etc/yum.repos.d with 18.12
- Perform yum update and then reboot the machine
On sipxconfig service startup following steps are taken (in case there is a backup still on the disk):
- Restore mongo config and dbs, then remove from disk
- Reboot machine
For other cluster servers:
- Run same script
- Re-add databases that were removed.
Continue? (you must enter Yes or No as shown and press Enter):
Enter 'Yes' and press Enter to continue. The system will reboot a couple of times as part of the process.
Login to the Admin GUI and click on System -> Backup and at a minimum backup configuration and voicemail.
Do it now... before you go any further.
From the Admin UI remove databases from all nodes except for the primary node. Click on System -> Databases do accomplish this.
Proceed as above with the 'Download upgrade.sh' section and then the 'Run upgrade.sh' section.
After the Primary Server has completed, repeat for each of the Secondary Servers in the cluster until all are completed.
After the secondary nodes are complete and done with their reboots, log in to the Admin UI and add back the database nodes that were removed.
Login to web interface as superadmin.
Navigate to System -> Servers page. Place checkmark next to server names and click 'Send Profiles'.
When upgrading uniteme from openUC 4.6 Update 11 or 14.4.3 to 15.06 follow these steps to ensure the SEC service is correctly running:
If you have manually modified any system related files or some files are not as yum would expect them to be, the yum update process may not overwrite them. It will instead create 'rpmnew' or 'rpmsave' files and not overwrite the files. The administrator may have previously modified the files knowingly or as part of a patch supplied by TAC.
To check your upgrade.log and search for *.rpmnew *.rpmsave on your system check the upgrade log:
You will be responsible for merging any changes from the old file to the new or contacting Technical Support if you require assistance.
Please see the Getting Support section for support tips and support contact information
|Jira #||JIRA Name||RN Content||Enhancement/Fix/Known Issue||Key words|
|SIPX-753||Add support for Polycom VVX 150, 250, 350 and 450||Polycom is adding some new VVX phones to their lineup.|
This is mostly a hardware refresh. Firmware 5.8.x and later supported.
|SIPX-755||Add alarm for Certificate expiration||Add a system alarm called Certificate_Expiration that generates an alarm at 2 weeks before any system certificate is to expire.||Enhancement||Alarms|
|SIPX-758||Missing user and password field for Grandstream https conf file authentication||An administrator would like to use an external provisioning server that serves profiles trough https using user password authentication, the problem is that in the profiles for the upgrade section there are options for user and password for firmware but not for config which needs to bee kept safe more than firmware.||Enhancement||Grandstream|
|SIPX-763||Alarms should be grouped and in alphabetical order||Alarms in the administration portal should be logically grouped and in alphabetical order, so that related alarms can be displayed adjacent to each other. Now the order seems random and it is hard to find anything except by searching. Alphabetical ordering would put for example|
next to each other, and so on, since the alarm name is hierarchical. Same for MONGO alarms and so on.
|SIPX-766||Make mongodb cache size configurable||Make mongodb cache size configurable in Admin GUI. System -> Database -> Settings. This is beneficial for systems with small amounts of memory.||Enhancement||MongoDB|
|SIPX-780||upgrade mongodb to 3.6.9||Upgrade mongodb to version 3.6.9 as resilience is improved.|
Tests for a customer who wants to upgrade to 3.6 revealed that the upgrade from 3.4 to 3.6 is straightforward and can be done in place. This will also fix, among others, an issue where Mongo could not recover sometimes after the machine was shut down forcibly / powered off and the only solution was to delete the database and database files and replicate again. This was due to an empty storage.bson file:
The 3.6 version also adds performance improvements.
"Always-on write availability
Retryable writes reduces the error handling you have to implement in your code. The MongoDB drivers will now automatically retry write operations in the event of transient network errors or primary replica elections, while the server enforces exactly-once semantics."
Recommended version by Mongo developers is 3.6.9, tested OK, storage.bson bug seems fixed, tested by multiple power offs of nodes, reelections run smoothly and cluster comes back online with improved speed vs. 3.4 version, even before all services are loaded.
|SIPX-781||Enable autoprovisioning of new Polycom VVX 150,250,350 and 450 phones||The new Polycom VVX 150,250,350 and 450 phones fail to autoprovision. Investigation has found that the system does not generate configuration files because it does not recognize the user agent.|
"2018-12-20T12:43:06.694000Z":262::INFO:centos7.iuliu.test:SocketListener1-1:00000000:Servlet:"GET /64167f3a750d-sipx-applications.cfg User-Agent: FileTransport PolycomVVX-VVX_450-UA/126.96.36.19973 Type/Application"
"2018-12-20T12:43:06.695000Z":263::DEBUG:centos7.iuliu.test:SocketListener1-1:00000000:Servlet:"Un-recognized user-agent or path. Redirecting to sipXconfig."
With manual generation of configuration files the phones work fine.
It seems that the servlet source code should be updated:
No. of lines:
VVX 150: 2
VVX 250: 4
VVX 350: 6
VVX 450: 12
|SIPX-782||Clean up and update Polycom config files||Config file templates for Polycom phones are outdated and give out many errors.||Enhancement||Polycom|
|SIPX-783||CF engine doesn't trigger when Admin Settings are changed changed in UI||Changing SELinux setting in UI doesn't trigger CF engine to modify /etc/selinux/config file.||Fix||Config|
|SIPX-784||Wrong title in About window||There is a wrong title in About window.||Fix||Config|
|SIPX-791||Enhancement: remove user from phone automatically and send profiles upon deletion||As summary describes, enhancement request to automatically remove the user from any assigned phones upon being deleted from sipxconfig. |
Should also be the case with LDAP if user is set to be deleted or suspended from the system.
Should also remove any shared lines or lines with presence subscribed.
When the administrator deletes a user, the administrator should be prompted letting them know that the user will be deleted from the system and removed from any system managed phones.
|SIPX-792||Populate SIP Domain in the Outbound Proxy field of Shared Lines for HA||In an HA cluster, the Phone->SIP Lines->Outbound proxy field must be provisioned with the SIP domain name (e.g. lvtest.com when server names are pbx.lvtest.com, pbx2.lvtest.com, pbx3.lvtest.com) for shared lines, and not the Phones->MAC Address->SIP Servers-> Servers field. Otherwise failover to the secondary servers for private and shared lines to the secondary servers does not work when the primary server is down. |
In the Polycom Release 5 system administration panel, follow the setup for the Genband MADN-SCA features. The reg.x.outboundproxy.address should be used as the IP address of the SIP server for shared lines.
|UC-4540||zen 7181: voicemail fwd with comment to email||Customer requested an improvement to the voicemail -> email forwarding:|
"It looks like if you press 5 to forward a copy of a voicemail, and record additional comments, and the destination mailbox has email forwarding enabled, then the email that gets sent out with the voicemail attached doesn't contain the comments. If you check the forwarded message using the phone you hear the comments, but the WAV file attached to the email doesn't have the comments."
|UC-4624||zen 7314 : http provisioning option to dhcp config||An administrator would like to easily configure our dhcp service to add http provisioning options. Customer requested .. :|
If I check the box "Polycom HTTPS provisioning" in System -> DHCP, there is a new line in /etc/dhcp/dhcpd.conf:
option option-160 "https://sipxecs.procaresystems.com/phoneprov";
When I uncheck that box, that line disappears, so the phone appears to use FTP. It would be good to have a 3rd option to use http, and wondering if that should be the default option.
Another thing I discovered, when I uncheck User -> Hoteling -> Enable, then try to log in to a phone, the log says hoteling is not enabled for the user, but it the phone still logs them in fine:
"2017-11-03T20:08:55.316000Z":40:JAVA:INFO:sipxecs.procaresystems.com:P2-17:00000000:HotelingServlet:"Getting configuration for phone:64167f083e6b; user:1341"
"2017-11-03T20:08:55.317000Z":41:JAVA:ERR:sipxecs.procaresystems.com:P2-17:00000000:HotelingServlet:"Hoteling is not enabled for user: 1341"
I'm guessing maybe the configuration files don't get deleted. Any suggestions on this, or can we file a JIRA?
I was able to get hoteling to work for the users that wouldn't work, I'm not sure how though. It doesn't seem to be related to being a Reach agent or the group it was in, I didn't change those, but there was an old Jitsi phone provisioned that may have interfered (it was named the same as the user).
|UC-4741||zen 7856 / 7858 - 18.04 postgresql password change causes issues||Customer upgraded to 18.04 and changed postgresql password in system -> admin. This seems to have broken hotel. Advised customer to remove postgresql password, which fixed hotel, but broke CDR. Dev requested from customer ..|
"callresolver log says:
"2018-07-23T10:59:09.226647Z":2:CDR:ERR:sip01.ipt.prod.int.phx2.redhat.com:main:00000000:cdr:"cse_reader.rb:: Loss of connection to database #<struct DatabaseUrl database=\"SIPXCDR\", port=5432, host=\"sip03.ipt.prod.int.phx2.redhat.com\", adapter=\"postgresql\", username=\"postgres\", password=\"\"> - retrying to connect after sleep"
"2018-07-23T10:59:09.403025Z":3:CDR:ERR:sip01.ipt.prod.int.phx2.redhat.com:main:00000000:cdr:"cse_reader.rb:: Loss of connection to database #<struct DatabaseUrl database=\"SIPXCDR\", port=5432, host=\"sip01.ipt.prod.int.rdu2.redhat.com\", adapter=\"postgresql\", username=\"postgres\", password=\"\"> - retrying to connect after sleep"
password used by callresolver is retrieved from: config.fetch('SIP_CALLRESOLVER_DB_PASSWORD', '')
so we need also file: /etc/sipxpbx/callresolver-config
specifically, field: SIP_CALLRESOLVER_DB_PASSWORD"
.. and customer replied :
That was the issue, seems password removal was not propagated.
but few servers had
password = adasdasd
sipxagent fixed it.
|UC-4751||CSR has the wrong organization name||When using the Uniteme WebUI to create a CSR it ignores the user input for the organization and inputs the default instead. See attached images for example.||Fix||Config|
|UC-4768||Implement automatic SSL certificate with Let's Encrypt||The Admin server and the UnitemeWeb should have an automatic SSL certificate generation so when deploy in an MSP model, there is no manual management of certificate.|
The method to use should be well described in the Let's Encrypt web site. Otherwise, there are good example to get the mechanism done for Reach3 or Rocketchat for example (https://rocket.chat/docs/installation/paas-deployments/aws/#5-configure-nginx-web-server-with-tlsssl)
|UC-4778||sipxagent.log does not have timestamps||The cfengine sipxagent.log does not have timestamps, which makes it difficult to troubleshoot. There should be timestamps added to the log, otherwise we are just guessing what happened when. This can be achieved by adding -l (low case L) or --timestamp option||Enhancement||Config|
|UC-4798||apache rewrites and provisioning files||When attempting to download custom configuration files phones will get a different result depending on the path specified in dhcp option 160. For example, phone will get a different result depending on the path requested from /phoneprov/custom.cfg to /custom.cfg.||Fix||Config|