We have lost our Zulu UC screen pops which are set at the incoming route level. The logs show that __ZULU_URL= is being set at the incoming route level. As far as I can tell unlike topic 41293 they are not being replaced by a queue or something else. This is occurring on two up to date mac’s, and was also happening before we did the lastest client upgrade/restart.
Yes, we are answering the call in the client, call audio and messaging seem fine. I do not believe there are any additional firewalls or blocked ports on the client computers. Which port would I need to have open for the popups to work? A few weeks back I did review this document to make sure all of the needed incoming ports were open on the server.
These screen pops worked before, and now they do not. The only changes which have been made are the upgrades to the latest version of FPBX and the Zulu client.
One issue we had was similar to this. Even though there was no record of blocking, we had to disable SOPHOS on the client, reinstall Zulu, then it worked. After we had a successful test, we enabled SOPHOS again, without changing anything. Zulu kept working.
So on Machine A, I uninstalled Sophos, rebooted, reinstalled Zulu, still nothing. Machine B does not have Sophos on it, but we reinstalled/rebooted on that one too with the same result.
Maybe take a look at the Zulu logs on the client when the call comes in and see if you see anything? Zulu is a commercial product, so you should be able to open a ticket and receive support as well.
Oddly enough I don’t see anything in the logs relating to the ZULU_URL or what I would expect to be a related variable. Also, I don’t see anything in these logs about the incoming call, but that might be masked where I see selectedInteraction - asdfasdfasdfasdf. I’m just speculating at this point.
If you haven’t already I highly suggest opening a commercial module ticket with us at support.sangoma.com so that we can take a look and see what’s may be going on here.