Child pages
  • sipXcom 20.08
Skip to end of metadata
Go to start of metadata

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

  1. 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.
  2. AudioCodes and other gateways may need to have their configuration changed if faxing is used. See SIPX-811.
  3. 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 NameRN ContentEnhancement/Fix/Known IssueKey words
SIPX-835Update freeswitch flite RPMsFlite 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
FixConfig
SIPX-841Create HuntGroup (callGroup) REST serviceSuport for Hunt Group REST service to mimic HuntGroup page functionalityNew FeatureAPI
SIPX-843Variant not passed in Rest API PUT methodThe variant is not passed in PUT method, so the JSON mapping cannot be done

FixAPI
SIPX-844SIP MESSAGE created call loopCustomer 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
FixCounterpath
SIPX-845sipximbot doesn't load when SIP domain is different than network domainIt 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());
FixConfig
SIPX-846Add order direction query param when retrieving cdrsorderDirection=asc for ascending orderingEnhancementCDR, API
SIPX-849Create REST service to retrieve user registrations per groupcurrently only all system registrations or registrations per user can be retrievedEnhancementAPI
SIPX-850Hunt group callingAn 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).EnhancementConfig
SIPX-853Block IP's obtained from APIBANIn 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.
EnhancementSecurity
SIPX-854improve backup/restore to contain 3rd party collections from profiles databasedump/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 dbEnhancementBackup
SIPX-855CDR REST Service for user - add option to take the recipient into accountIn 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
EnhancementAPI
SIPX-856Change Hunt Group replication from lazy to eager methodCurrently 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
EnhancementConfig
SIPX-857sipxproxy Mongo DB cache expire time is restricted to minimum 30There are scenarios when 30 is too much. change 30 with 5EnhancementConfig, Mongo
SIPX-860Clickjacking - User interface redress attackPEN Tests (Penetration tests) complains.
Proposed resolution: add http header: X-FRAME-OPTIONS: deny
the equivalent is: "Content-Security-Policy", "frame-ancestors 'none'"
EnhancementSecurity
SIPX-861Rest Service to DELETE cdrs given prefixRest signature is:

https://${sipxconfig_host}/sipxconfig/api/extendedcdrs/delete/${prefix}
EnhancementCDR, API
SIPX-862REST API CDR Call Missing one CallWhen 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.
EnhancementCDR
SIPX-865Calls missing from CDRsFor 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.FixCDR
SIPX-879CDR 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 <>.FixCDR
UC-1743Investigate DST updates in schedules, voicemails, cdrs, etc.Revisit DST fixes. Found an additional problem and correctedFixConfig
UC-4847Extended CDR REST ServiceA customer needs to add extra information related to a CDR history call.EnhancementCDR
UC-4852Sipxconfig fails to start after upgradesipxconfig 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)
FixConfig
UC-4855Set permissions via REST when create/modify userUpgrade REST service for users to set/get permissionsEnhancementAPI
  • No labels