sipXcom 20.08 General Availability
December 18, 2020
Summary
Happy Holidays!
CoreDial is pleased to announce the GA release of sipXcom 20.08.
We're bringing in some new API enhancements to sipXcom for CDR reporting as well as the new ability to manage Hunt Groups via API.
We’ve also taken the next step with the new API Ban feature, where we’ve introduced the firewall blocking of the imported entries. Check out their site (https://apiban.org), they're offering a great service. All you need to do is request an API key and you can have sipXcom automatically poll their honeypot-created ban list.
We’re looking forward to a great 2021 with more enhancements to come!
Highlights
sipXcom New Features
- Manage Hunt Groups via API
sipXcom Improvements:
- Blocking of imported IP’s from API Ban.
Notes
- 19.08 and later are now released on CentOS 7 only. This will require that administrators install CentOS 7 minimal, then install Uniteme with our single line installer and then restore from a previous version backup.
- AudioCodes and other gateways may need to have their configuration changed if faxing is used. See SIPX-811.
- For Let's Encrypt certificates to work properly, the server must have a valid outside DNS name and have port 80 and 443 open to LE's servers.
Who Should Install?
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.
Questions
Please post to the sipXcom-users google group if you have questions.
https://groups.google.com/forum/#!forum/sipxcom-users
Specific Issues Addressed
| Jira # | JIRA Name | RN Content | Enhancement/Fix/Known Issue | Key words |
| SIPX-835 | Update freeswitch flite RPMs | Flite is broken in our rpms, the module does not load, needs updating: From here https://files.freeswitch.org/repo/yum/centos-release/7/x86_64/ Flite must be version 2.0.0-1 not 2.0.0-0 flite-2.0.0-1.el7.centos.x86_64.rpm 2017-01-12 22:27 13M flite-debuginfo-2.0.0-1.el7.centos.x86_64.rpm 2017-01-12 22:27 19M flite-devel-2.0.0-1.el7.centos.x86_64.rpm 2017-01-12 22:27 36K | Fix | Config |
| SIPX-841 | Create HuntGroup (callGroup) REST service | Suport for Hunt Group REST service to mimic HuntGroup page functionality | New Feature | API |
| SIPX-843 | Variant not passed in Rest API PUT method | The variant is not passed in PUT method, so the JSON mapping cannot be done | Fix | API |
| SIPX-844 | SIP MESSAGE created call loop | Customer reported that a user using Bria sent a IM over SIP, which seems to have bypassed the dialplan authentication rules and created a call loop between the server and gateways. Log trace example in UC-4848. One way to mitigate this might be to add firewall rules to drop this traffic, like .. -A INPUT -i eth0 -p tcp -m tcp --dport 5060 -m string --string "MESSAGE sip:" --algo bm --to 65 -j DROP -A INPUT -i eth0 -p udp -m udp --dport 5060 -m string --string "MESSAGE sip:" --algo bm --to 65 -j DROP -A INPUT -i eth0 -p tcp -m tcp --dport 5061 -m string --string "MESSAGE sip:" --algo bm --to 65 -j DROP | Fix | Counterpath |
| SIPX-845 | sipximbot doesn't load when SIP domain is different than network domain | It looks like that, in single server configurations, if the network domain is different than the SIP domain (e.g. SIP domain is sipx.iuliu.test and network domain is iuliu.test), the IM bot ("MyBuddy") fails to connect to the openfire IM service. Investigation has found that in /etc/sipxpbx/sipximbot.properties The key imbot.openfireHost=iuliu.test should point to the actual openfire machine (sipx.iuliu.test) not to the network domain (iuliu.test). There's also a possibly (?) related message in /var/log/messages May 6 07:32:30 uniteme cf3[6614]: Because the regular expression "info|INFO" still matches the replacement string "#011#011<level value="INFO" />#015" May 6 07:32:30 uniteme cf3[6614]: Promise (version not specified) belongs to bundle 'sipxopenfire_log4j_xml_contents' in file '/usr/share/sipxecs/cfinputs/plugin.d/sipxopenfire.cf' near line 247 Research has shown that imbot.openfireHost= parameter in /etc/sipxpbx/sipximbot.properties is set by ImBotConfiguration.java through the command: config.write("imbot.openfireHost", domain.getNetworkName()); This should probably be changed to: config.write("imbot.openfireHost", domain.getName()); | Fix | Config |
| SIPX-846 | Add order direction query param when retrieving cdrs | orderDirection=asc for ascending ordering | Enhancement | CDR, API |
| SIPX-849 | Create REST service to retrieve user registrations per group | currently only all system registrations or registrations per user can be retrieved | Enhancement | API |
| SIPX-850 | Hunt group calling | An administrator would like to be able to have an additional hunt group calling feature added. The next call to a hunt group should continue with the next user following the last user contacted (completed call). | Enhancement | Config |
| SIPX-853 | Block IP's obtained from APIBAN | In 20.04 we implemented APIBAN support but didn't add the ability to block those IP's obtained from the APIBAN query. An administrator would like the ability to add APIBAN obtained addresses to the firewall rules and block them automatically. | Enhancement | Security |
| SIPX-854 | improve backup/restore to contain 3rd party collections from profiles database | dump/restore profiles mongo database generically for all collections. The improvement is aplicable for 3rd party apps that may need to create new collections in profiles db | Enhancement | Backup |
| SIPX-855 | CDR REST Service for user - add option to take the recipient into account | In cases like when the user is part of a hunt group, and that hunt group is called, a ring (user) answers. Add option to take that cdr into account when query. Example: curl -v -k -X GET -H "Content-Type: application/json" https://superadmin:Phoenix01@localhost/sipxconfig/api/extendedcdrs/user/201/history?fromDate=197002071228\&recipient=true note the recipient flag. when true, the callee_contact field is taken into account | Enhancement | API |
| SIPX-856 | Change Hunt Group replication from lazy to eager method | Currently when a change is done in huntgroup rings, a lazy mongo replication is used. For mongo entities only eager replication is recommended. Lazy replication is meant for configuration files | Enhancement | Config |
| SIPX-857 | sipxproxy Mongo DB cache expire time is restricted to minimum 30 | There are scenarios when 30 is too much. change 30 with 5 | Enhancement | Config, Mongo |
| SIPX-860 | Clickjacking - User interface redress attack | PEN Tests (Penetration tests) complains. Proposed resolution: add http header: X-FRAME-OPTIONS: deny the equivalent is: "Content-Security-Policy", "frame-ancestors 'none'" | Enhancement | Security |
| SIPX-861 | Rest Service to DELETE cdrs given prefix | Rest signature is: https://${sipxconfig_host}/sipxconfig/api/extendedcdrs/delete/${prefix} | Enhancement | CDR, API |
| SIPX-862 | REST API CDR Call Missing one Call | When the customer makes a REST CALL: https://server/sipxconfig/rest/my/redirect/cdr/17993?fromdate=20201005 He misses one CDR Entry. I've looked into the source code and found out, that the offset variable is initialized to 1. https://github.com/sipXcom/sipxecs/blob/5f114bb5aeacc4a342574df185b4c75c4817d27c/sipXcdrLog/src/org/sipfoundry/sipxrest/cdrlog/CdrLogRestlet.java#L75 If I use the SQL Query with OFFSET 1 I miss one call. If I set it to 0 all Calls are shown. So I think line 75 should be changed to offset = 0; Currently I hope we can bypass the problem with https://server/sipxconfig/rest/my/redirect/cdr/17993?fromdate=20201005&offset=0 so the problem isn't critical. | Enhancement | CDR |
| SIPX-865 | Calls missing from CDRs | For some calls with duration 0, only "call end" event is triggered. We do not set from_tag, caller_aor, callee_aor for such event. These fields are constrained to be not null for the cdr to be saved in database. The fix will consist to retrieve these fields values from the call end event as well. | Fix | CDR |
| SIPX-879 | CDR filter without <> | This filters for SIP URIs of the type <sip:......@...> but I've found some callee_aor inside of the CDR Table that are "sip:43144@voip.xyzcust.com". So they are without <>. | Fix | CDR |
| UC-1743 | Investigate DST updates in schedules, voicemails, cdrs, etc. | Revisit DST fixes. Found an additional problem and corrected | Fix | Config |
| UC-4847 | Extended CDR REST Service | A customer needs to add extra information related to a CDR history call. | Enhancement | CDR |
| UC-4852 | Sipxconfig fails to start after upgrade | sipxconfig would not start after an upgrade to a newer version. Both of these used previously 17.10 and earlier config. Steps to reproduce: install 19.12, restore customer config, upgrade to 20.04 or 20.08 https://ezuce.zendesk.com/agent/tickets/8938 sipxconfig starts with nofork option in foreground Seems to be related to PostgreSQL (log attached). No errors are present in sipxconfig log Manipulating the sipxconfig service file did not fix it (added postgresql.service to after and a delay of 10-30 seconds before start) | Fix | Config |
| UC-4855 | Set permissions via REST when create/modify user | Upgrade REST service for users to set/get permissions | Enhancement | API |