sipXcom 25.01 Feedback

[sipXcom Newbie]

Hi there OnRelay Support,

Thanks for making 25.01 beta available to the community. Please find below f/b and an issue.

Environment: On-premise, un-clustered, configured with single, public, interface.

1. UI: System > Servers > Telephony Services

Text Network Queue could better differentiate between the two rows in which they appear.

2. UI: Users Aliases repeating group field. Unable to remove entries.
E.g. Assume existing User Aliases = "String1 String2" (upon display).
User clears field and enters "String3".
Upon re-display, Aliases = "String1 String2 String3"

3. SYS: Possible incompatibility with packages updated since 25.01 built.
Symptoms: Previously achieved a "green" `systemct status` with all telephone services enabled.
Following `sipxecs-setup --reset-all` and several days repetition of `dnf update -y` no longer obtain clean reboot.
Tried disabling some services in the UI, specifically:
- Callback on Busy
- Paging Groups
- Presence
(Instant Messaging and Device Provisioning never changed, so at their defaults), and disabled unused Core Services, specifically:
- SNMP Alarms
- SNMP
(DHCP never changed, so disabled by default)
Also ran the reset keys procedure described in the online documentation, specifically:
`sipxagent`
The first time, this enabled previously disabled services:
```
# sipxagent
Created symlink /etc/systemd/system/multi-user.target.wants/sipxrest.service /usr/lib/systemd/system/sipxrest.service.
Created symlink /etc/systemd/system/multi-user.target.wants/sipxrls.service /usr/lib/systemd/system/sipxrls.service.
Created symlink /etc/systemd/system/multi-user.target.wants/sipxsqa.service /usr/lib/systemd/system/sipxsqa.service.
Restarting failed sipXecs services from the UI and manually restarting failed units, could not 'get to green'.
Last `systemctl status` attached.
There are services there shown as both disabled and failed (e.g. sipxrls), and sipxpublisher core-dumps.

Thanks in advance

Kind regards

sipXcom Newbie

[Support]

Hello,

Thank you!!

While we decipher that, it would be helpful if you could send us sipxconfig.log captured with DEBUG level logging enabled after a full service restart.

If anything privacy sensitive in there, you may also email it to us directly.

We will soon publish update 2 on the main 25.01 branch, which is the update we intend to take live for ourselves, and will endeavor to include some of these fixes / issues.

Thanks again.

> <systemctl_status_2026-05-14_1025>

[Support]

Hello,

Thanks for the logs.

At first glance nothing unusual in the sipxconfig.log, but this error from the sipxcdr service startup script indicates something is seriously wrong or corrupt with the local PostgreSQL DB. 

May 14 11:02:36 sipXecs sipxcdr[1530]: psql: error: could not connect to server: No such file or directory

May 14 11:02:36 sipXecs sipxcdr[1530]:         Is the server running locally and accepting

May 14 11:02:36 sipXecs sipxcdr[1530]:         connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

If you could also send us the sipregistrar.log with DEBUG enabled we should be able to quickly see why it is not coming up. A qualified guess is it is similar to the above.

You can also attempt to run these commands from command line to check the state of the DB.

psql -U postgres sipxconfig 

psql -U postgres sipxcdr

Having said that, there is a very good chance something corrupted has not been repaired with sipxecs-setup reset-all commands. 

And since that command in any case takes you back to square one config-wise for sipXcom; would rather recommend a fresh install to ensure you start from a clean slate.

Note sipxecs-setup reset-all does not erase the entire DBs, it just resets table contents. To clear the entire DBs and configs, you must e.g. do:

systemctl stop postgresql

rm -rf /var/lib/pgsql/data/*

systemctl stop mongod

rm -rf /var/lib/mongodb/*

And to clear all sipXcom data you must uninstall and run:

rm -rf /etc/sipxpbx

rm -rf /var/sipxdata

rm -rf /var/log/sipxpbx

rm -rf /var/run/sipxpbx

But again, it is likely something corrupted may still linger, since CF engine configures system settings elsewhere as well, and you are likely much better off with a server install from scratch, alternatively a recovery from a system file image backup at your last working state.

[Support]

All, going back and forth over this we eventually reproduced and found that this problem is most likely due to the reboot service startup order. The problem recovers with a manual sipxecs service restart following a reboot.

In 25.01 the service scripts have had a major overhaul as we have moved everything to systemctl and sipx*.service scripts. And these scripts are missing startup dependencies to postgresql.service  and mongod.service.

It is a simple, and safe, fix that will be included in the upcoming update 2.

Another major fix in update 2 is a resolution for the hazelcast search index that is not always refreshing reliably. It is an old issue that appears more frequently now, just a simple software logic bug.

We have also done a few UI enhancements including a better confirm dialog.

And last we will also see if we can quickly figure out for update 2 why custom logo property overrides are not taking effect.

[sipXcom Newbie]

All,

Exchanged a few logs with OnRelay Support. It's clear they actually
attempted to reproduce, so kudos to them.

Docs do say it's verified to work only in a single interface config.
Much of my woes were introduced by going against that and trying to
have a second, private, interface up but concealed from sipXecs.

OnRelay have their reasons and workarounds, though as it's a little
unconventional to manage over a public interface, a "Could Have" is
for dual interface support longer-term.

If using sipXecs's internal DNS server and forwarding onsite to your
own (the default "Managed" DNS setting in the UI), you may wish to
check that 'localhost' (resolves in addition to 'localhost.') Not
resolving will definitely prevent several sipx* services starting
and communicating with each other.

Looking forward to the forthcoming 25.02.

Have a great weekend.

sipXcom Newbie

[OnRelay Support]

We have just published update 2 on 25.01, which includes the above mentioned service script fixes, a fix for refreshing the search index, a new confirm UI and some minor UI polishing.

[sipXcom Newbie]

Awesome, thanks -- appreciated.

sipXcom Newbie

[Roy Reynolds]

Thanks. Hopefully I can check it out and provide feedback when possible. 

On Mon, May 18, 2026, 2:12 PM sipXcom Newbie <sipxcom-text...@tel.co.uk> wrote:

Awesome, thanks -- appreciated.

sipXcom Newbie

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sipxcom-users/20260518191245.5892a934%40tel.co.uk.

[OnRelay Support]

Thanks Roy,

We have also looked at the custom icon issue you raised.

It is tricky since Spring's security mechanisms have become much more restrictive about loading sipxplugin.beans.xml files from the target file system that are not packaged in a .jar on the classpath. 

So the issue remains open until we figure out how to get alternative custom skin properties loaded from the file system in a general manner.

[Roy Reynolds]

Thanks for the heads up. You all do a fantastic job. 

To view this discussion visit https://groups.google.com/d/msgid/sipxcom-users/4788a05c-0c8c-4f47-b395-8f02e7d21966n%40googlegroups.com.