May 10, 2019
eZuce is pleased to announce the General Availability of sipXcom 19.04.
There are again two releases for sipXcom 19.04, one for CentOS 6 and one for CentOS 7. The documentation around Installations and Downloads is being updated now with CentOS 7 as the recommended OS moving forward. We'll also update the video to cover CentOS 7 Minimal installation. While this is a relatively 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. This would result in traffic floods of SIP traffic with bad subscribes to MWI and invalid registrations to the server.
The new Polycom VVX ‘50’ series phones are now supported for configuration as well as auto-provisioning. Firmware versions 5.9.0 and later are supported.
Also, mongoDB has been updated to 3.6.11. This has had a positive effect in recovery from a node outage. The new mongodb seems much more resilient.
Please note that this will be the last release for CentOS 6. As of version 19.08 we will only be releasing sipXcom for CentOS 7! To go from a CentOS 6 based system to a CentOS 7 based system will require a backup and restore to a fresh CentOS 7 installation. As such a parallel install will be recommended.
We’ve also decided to put the container (Docker) work on hold for now. There were complexities around networking and implementation that we didn’t feel warranted the effort involved to work past them. Additionally, there wasn't significant customer demand to warrant the effort at this point. We’re pushing ahead with some newer features instead.
sipXcom New Features:
- 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 a certificate from Let’s Encrypt.
- Sort alarms alphabetically
- Upgrade mongodb to 3.6.11
- Add http provisioning option to DHCP configuration
- Full Beta Release Notes with installation information are located here: 19.04 Full 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.
Who Should Install?
This release is recommended for all production installations.
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.
Please post to the sipXcom-users google group if you have questions.
Issues Sorted by Issue Number
|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/22.214.171.12473 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|