Content Comparison

Sometimes psip-pms can get stuck in sync mode.  During this time, you will not be able to modify the system and there appears to be no way to release it from this mode.

You can override it and return the system to normal operation by issuing the following command:

echo "test xml synch 0" > /var/lib/docker/volumes/voiceware_sockets/_data/psip-pms-cli-pipe

There should be no output and should return immediately. After issuing this command, the web interface should start working again.

At times the Psip process pmsping.php can become stuck. When this happens Psip stops processing check in/out messages however they continue to display in the Psip debug window. If this happens do the following.

as root, run:
ps auwwx|grep pmsping.php
and look for output like this:
 

USER   PID   %CPU %MEM     VSZ   RSS TTY STAT START   TIME COMMAND
root   10993  0.0  0.3  201140 15824 ?   S    2022    8:24 /usr/bin/php -q /opt/asgi_scripts/pmsping.php 1663136941

 
Notice how it's been running since 2022?  That means it's stuck.  Another way to tell is to take the timestamp on the command (the very last parameter -- 1663136941 in this case) and convert that to a timestamp using https://www.epochconverter.com/

In any event, if you see that process still running on the host it's probably safe to kill it.  Take the PID of that stuck process and issue a kill, as such:
sudo kill -9 10993
Replacing 10993 with the actual PID from the output above.  Within a few minutes the host should clear up and things should get back to normal in situations such as this.

If your psip-pms interface is not working correctly and you are seeing a similar message in your logs

11:16:02 1 RPRSP 308 XMLRPC client threw ERROR: Unable to transport XML to server and get XML response back. HTTP response code is 403, not 200

This means that your XML RPC url is set incorrectly (or to 'localhost').  On newer dual-stack system, 'localhost' resolves to '::1'.  Unfortunately, the ACLs system in Voiceware only compares IPv4 addresses (127.0.0.1).  That means you need to change the URL from 'localhost' to '127.0.0.1' to force IPv4 connection.

You can edit it in the file:

/data/psip/configs/stub/psip-pms.stub

Log files and the log rotate process was changed in Voiceware version 4. As such the below documentation will be split between versions 1-3 and 4.

Run away log files, common causes

1. Psip-pms log file being filled with garbage data when a Serial interface is denoted but does not exist.

2. Hacking bot scanners. If a system is left open on port 80 a hacking bot trying to download Polycom configuration files can find and start scanning a system. For every file scanned for a log entry will be created. Depending on the bot this can cause large log files.

Voiceware version 1-3

Log files are located in /var/log or /var/log/voiceware

Log files are rotated with the based on a varying schedule based on process. The log rotation is handled by logrotate. You can find the definitions in /etc/logrotate.d.

The most common reason for the logs to not properly rotate is due to the permissions of the logrotate definitions. To fix:

chown -R root:root /etc/logrotate.d

To diagnose a possible problem with logrotation, you can issue:

logrotate -d /etc/logrotate.conf

This will show what would be done, but does not execute any commands. Removing the -d would cause it to run, but I do not recommend doing this by hand as it changes the timestamps on the files managed by logrotate and can alter how rotations are handled.

Voiceware version 4

Almost all logging is handled via journald. This is the logging process that is part of the new SystemD project. All of the major Linux distributions use this new system. The binary log files are stored persistently in /var/log/ journal but those files are not text files you can read with an editor. They can be accessed using the journald command. These files are rotated as needed, but are limited by the amount of disk space available. The smaller or less free disk space, the shorter a period is covered by the running journal.

Persistent text logs written by rsyslogd are located in the /var/log/. These is rotated weekly and compressed to save space.

To follow the running journal:

journalctl -f

To limit it by Unit or Process (Note this starts from the beginning of the journal):

unit: journalctl -u <unit>

tag: journalctl -t <tag>

You can further limit this by time.

journalctl [-t <tag>] [-u <unit>] --since=<YYYY-MM-DD|'today'|'yesterday'>

If a systems CDR retention settings are changed from say 200 days to 100 days older logs might not be removed. To purge the older CDR records run the below command.

sudo docker exec -it scheduler /opt/asgi_scripts/recorded_calls.php

There will not be much output but it will remove all older CDR records and reduce the size of backups. (It would be advisable not to run this during the day on a busy system)

At times an ISP will block port 25. This port is the default port that Voiceware will use to send email messages. If the port is blocked the below commands can be ran to place a temporary fix into IPTables.

iptables -t nat -A OUTPUT -d 3.225.168.171 -p tcp --dport 25 -j DNAT --to-destination 3.225.168.171:587
iptables -t nat -A OUTPUT -d 107.21.150.142 -p tcp --dport 25 -j DNAT --to-destination 107.21.150.142:587
iptables -t nat -A OUTPUT -d 35.169.76.128 -p tcp --dport 25 -j DNAT --to-destination 35.169.76.128:587
iptables -t nat -A OUTPUT -d 34.204.28.179 -p tcp --dport 25 -j DNAT --to-destination 34.204.28.179:587
iptables -t nat -A OUTPUT -d 52.0.106.229 -p tcp --dport 25 -j DNAT --to-destination 52.0.106.229:587

Sometimes a system will fail to renew the certificate and will have the error “PR_END_OF_FILE_ERROR” when you try and browse to the site. The fix is to remove the webapps container and rebuild it then do the SSL cert installation process again from scratch.

docker rm -f webapps
voiceware start

voiceware ssl

If a DID is set as a user extension in the Dial Plan page when you load the Settings page you might receive the below error.

Fatal error: Uncaught PDOException: SQLSTATE[22003]: Numeric value out of range: 7 ERROR: value "13039009102" is out of range for type integer in /usr/local/lib/php/PDOWrapper.class.php:355 Stack trace: #0 /usr/local/lib/php/PDOWrapper.class.php(355): PDOStatement->execute(NULL) #1 /var/www/html/phonesuite/settings.php(365): PDOWrapper->getAll('SELECT extensio...') #2 {main} thrown in /usr/local/lib/php/PDOWrapper.class.php on line 355

To fix this issue simply set the dial plan type to DID (from User) and the issue will be resolved. The issue will also be fixed in an upcoming version of Voiceware.

A bug in Voiceware that would cause Voiceware to fail to start processes (psip in observed cases) and would not allow you to restart Voiceware. This bug has been fixed. This bug only effected version 4.0.3.5.

Details

When attempting to run the Voiceware status command (or other Voiceware commands) the below would display.

A lock file already exists.
This means a process is already running
Check with other technicians and/or support personnel

Fix

Run the command rm /tmp/.voiceware* to remove the lock file and proceed. To permanently fix run the command yum install voiceware-osconfig and answer yes when asked if you want to download the files. No restart or other action is required.