I have recently upgraded to the latest Zulu app, and I am not able to register. I have followed the information in the wiki, enabling PJSIP, and such, and I am still having issues. The client reports: “There is an error trying to reach the server”. So, I tried telneting to the server on port 8002 and the connection is refused.
From there, I logged into the console and noticed the following errors repeating every 15 seconds or so:
[2018-08-01 12:10:43] ERROR[3604][C-00009d89]: res_stasis.c:1276 stasis_app_exec: Stasis app 'zulu-mobile-call-wait-processing' not registered
[2018-08-01 12:10:43] ERROR[3605][C-00009d89]: res_stasis.c:1276 stasis_app_exec: Stasis app 'zulu-mobile-call-registered-processing' not registered
[2018-08-01 12:10:43] ERROR[3606][C-00009d89]: res_stasis.c:1276 stasis_app_exec: Stasis app 'zulu-desktop-call-processing' not registered
What have I missed, and/or where can I look for more details in the logs?
I have some additional information from the zulu_error.log and zulu_out.log files. The error log indicates an issue reading the swagger JSON, while the out log indicates that Zulu is restarting multiple times a minute.
[root@vox ~]# tail /var/log/asterisk/zulu_err.log
2018-08-01 12:19 -04:00: Can't read swagger JSON from http://127.0.0.1:8088/ari/api-docs/resources.json
2018-08-01 12:19 -04:00: Can't read swagger JSON from http://127.0.0.1:8088/ari/api-docs/resources.json
2018-08-01 12:19 -04:00: Can't read swagger JSON from http://127.0.0.1:8088/ari/api-docs/resources.json
2018-08-01 12:19 -04:00: Can't read swagger JSON from http://127.0.0.1:8088/ari/api-docs/resources.json
2018-08-01 12:20 -04:00: Can't read swagger JSON from http://127.0.0.1:8088/ari/api-docs/resources.json
2018-08-01 12:20 -04:00: Can't read swagger JSON from http://127.0.0.1:8088/ari/api-docs/resources.json
2018-08-01 12:20 -04:00: Can't read swagger JSON from http://127.0.0.1:8088/ari/api-docs/resources.json
2018-08-01 12:20 -04:00: Can't read swagger JSON from http://127.0.0.1:8088/ari/api-docs/resources.json
2018-08-01 12:20 -04:00: Can't read swagger JSON from http://127.0.0.1:8088/ari/api-docs/resources.json
2018-08-01 12:20 -04:00: Can't read swagger JSON from http://127.0.0.1:8088/ari/api-docs/resources.json
[root@vox ~]# tail /var/log/asterisk/zulu_out.log
2018-08-01 12:22 -04:00: [8/1/2018 12:22:32 PM.776] [INFO] console - Client WSServer is listening on 0.0.0.0 on port 8002
2018-08-01 12:22 -04:00: [8/1/2018 12:22:32 PM.914] [INFO] console - Zulu Has Started
2018-08-01 12:22 -04:00: [8/1/2018 12:22:35 PM.906] [INFO] console - Client WSServer is listening on 0.0.0.0 on port 8002
2018-08-01 12:22 -04:00: [8/1/2018 12:22:36 PM.037] [INFO] console - Zulu Has Started
2018-08-01 12:22 -04:00: [8/1/2018 12:22:39 PM.038] [INFO] console - Client WSServer is listening on 0.0.0.0 on port 8002
2018-08-01 12:22 -04:00: [8/1/2018 12:22:39 PM.169] [INFO] console - Zulu Has Started
2018-08-01 12:22 -04:00: [8/1/2018 12:22:42 PM.180] [INFO] console - Client WSServer is listening on 0.0.0.0 on port 8002
2018-08-01 12:22 -04:00: [8/1/2018 12:22:42 PM.327] [INFO] console - Zulu Has Started
2018-08-01 12:22 -04:00: [8/1/2018 12:22:45 PM.370] [INFO] console - Client WSServer is listening on 0.0.0.0 on port 8002
2018-08-01 12:22 -04:00: [8/1/2018 12:22:45 PM.494] [INFO] console - Zulu Has Started
I was able to locate the file mentioned in the error log, but I am not certain that it is in the right place.
The “HTTP Bind Address” in the “Asterisk Builtin mini-HTTP server” section of the advanced settings is set to “127.0.0.1” and the Bind Port is 8088. Is that not where I should be looking?
I did just notice that a username and password is configured for REST in Advanced Settings, but there are no users configured in Asterisk REST Interface Users.
I also just checked the http status in the asterisk console. Does this look right?:
vox*CLI> http show status
HTTP Server Status:
Prefix: /asterisk
Server: Asterisk/13.19.1
Server Enabled and Bound to 127.0.0.1:8088
HTTPS Server Enabled and Bound to [::]:8089
Enabled URI's:
/asterisk/httpstatus => Asterisk HTTP General Status
/asterisk/static/... => Asterisk HTTP Static Delivery
/asterisk/ari/... => Asterisk RESTful API
/asterisk/ws => Asterisk HTTP WebSocket
Enabled Redirects:
None.
PS: I cannot seem to get the preformatted text tag to work here. Selecting text and clicking the icon in the toolbar causes the text to be indented, but some or all of the text still displays as normal in the post, and the BBCode “Code” tag ignores the line breaks. Is there a trick to it?
vox*CLI> http show status
HTTP Server Status:
Prefix:
Server: Asterisk/13.19.1
Server Enabled and Bound to [::]:8088
HTTPS Server Enabled and Bound to [::]:8089
Enabled URI's:
/httpstatus => Asterisk HTTP General Status
/static/... => Asterisk HTTP Static Delivery
/ari/... => Asterisk RESTful API
/ws => Asterisk HTTP WebSocket
Enabled Redirects:
None.
If I try to log into Zulu, I no longer get an error about being unable to connect to the server, I get an error of “There is an error with the credentials”. I did confirm that the user has Zulu enabled and I reset the password just in case. I am using username@<ip_address> as the login name.
Just putting an update here for the benefit of anyone else having a similar issue. In the end, I was able (with the help of support) to log into Zulu after disabling Fax for the user. That pointed us to an outdated FaxPro Module, which apparently does not work with Zulu 3.
When a licensed commercial module’s renewal period has expired, those modules show up as “Enabled and Up To Date” even when they are old and outdated (see the attached screenshot). To see that they are out of date in the Module Admin, you must select each individual module and check the “Renew” tab, below “ChangeLog” and “Previous”. This seems to be a significant oversight in the module admin, as there ought to be a status of “Online Upgrade Available - Upgrade Period Expired” or similar. Presenting text that a module is up to date when it is not seems to be a recipe for trouble, and quite frankly must be costing Sangoma money, as I would have renewed my license much sooner if I had been aware that the module was out of date due to the expired license.
For the benefit of the archives, I wanted to post here that I found this old, closed bug report about this same problem.
I think that, if one could poll the entire user community, almost none would think it makes sense that a module might report its status as “up to date” when, in fact, there were multiple newer releases available.
The fact that these modules do not show up on the “Show only upgradeable” page limits the visibility of expired licenses to admins, and why wouldn’t they be shown in the list of Upgradeable packages? After all, these modules are upgradeable, there is just one additional step in the upgrade process: renewing the license.
