Zulu - Cannot Login - Stasis App Not Registered

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?

Many thanks,

Tom

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.

[[email protected] ~]# 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
[[email protected] ~]# 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.

[[email protected] ~]# locate resources.json
/var/lib/asterisk/rest-api/resources.json

Looks like you’ve bound asterisk http to another ip address.

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?

If you check your http bind address in advanced settings, you will see that the default value is ::. You probably should revert it.

I removed the prefix of “asterisk”, and I reverted the address for http (it had been set to 127.0.0.1).

Now, the error log is no longer printing the same error, it is rapidly scrolling messages like these:

2018-08-01 13:15 -04:00: [8/1/2018 1:15:44 PM.747] [ERROR] console - Chat find chat session by token ZTcwNGMxYzEtMGQ4Ni00Yg==
2018-08-01 13:15 -04:00: [8/1/2018 1:15:44 PM.821] [ERROR] console - Chat find chat session by token NDRmYzYzYmUtYmFlMC00ZQ==
2018-08-01 13:15 -04:00: [8/1/2018 1:15:45 PM.018] [ERROR] console - Chat find chat session by token ZDViZGYzMGYtMWI3Yy00Ng==
2018-08-01 13:15 -04:00: [8/1/2018 1:15:45 PM.020] [ERROR] console - Chat find chat session by token ZjU2MjYwODctY2I5Mi00Zg==
2018-08-01 13:15 -04:00: [8/1/2018 1:15:45 PM.171] [ERROR] console - Chat find chat session by token MGZjNDY5ZDMtYjZjYS00Mw==

This is now what I get from the console:

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 [email protected]<ip_address> as the login name.

You should use commercial module support services.

Thank you.

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.

My $0.02, YMMV, and so on, thanks for listening.

Tom

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.