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.
- Zulu: v3.1.0-alpha+695 © Sangoma
- PBX: v22.214.171.124 © Sangoma
Are there any particular log entries or testing I can help with?
[2018-09-05 00:44:01] VERBOSE[C-0000012c] pbx.c: Executing [[email protected]:21] Set(“SIP/provider-xxxxxxx”, “__ZULU_RAW_TYPE=url”) in new stack
[2018-09-05 00:44:01] VERBOSE[C-0000012c] pbx.c: Executing [[email protected]:22] Set(“SIP/provider-xxxxxxx”, “__ZULU_TYPE=url”) in new stack
[2018-09-05 00:44:01] VERBOSE[C-0000012c] pbx.c: Executing [[email protected]:23] Set(“SIP/provider-xxxxxxx”, “__ZULU_URL=http://url.com/incoming.php?a=search&callerid_num=+15555555555&callerid_name=TheName&source=asdf”) in new stack
What is happening? There is no popup? The popup is missing information? More information is helpful.
Are you answering the call in the Zulu client?
Ours isnt working either.
There is no popup when we answer the call. Other than no popup being attempted, everything else seems to be working fine.
On one computer the default browser is chrome, on the other it’s firefox.
Are you answering the call in the Zulu client? Is there a firewall or blocked port on the client computer that might be blocking the popup?
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.
From memory, one machine has Sophos on it, but not the other. I’ll give it a shot tomorrow morning and report back my findings. Thanks!
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.
It appears that after the latest updates both server side and client side have solved this problem. Thanks for taking a look everyone.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.