Sangoma Completes Acquisition of Digium: Sangoma Press Release. Community FAQ: Sangoma and Digium Join Together FAQ
FreePBX | Register | Issues | Wiki | Portal | Support

Zulu UC 3 and Mobile


(Ted) #1

Congrats to Sangoma on a new Zulu UC 3. It is a truly nice softphone app that works great.
A few questions. Sorry I haven’t researched much about it, just decided to ask here.

  1. Will it have a video call and video conference feature?

  2. I cannot make Zulu Mobile to work on my android phone. Putting the full name in the account name, ext number for the user name and an fqdn of the pbx with a default port number that’s prefilled in the app. And it won’t connect. I have configured the server already and Zulu UC 3 apps work on both mac and pc. On the mobile it just says connection closed.

  3. When calling from a windows app, the call doesn’t ring the phone instantly like all other phones do. It is delayed like one or two seconds and then starts ringing the phones. But when calling from a mac, the call gets to all the phones right away. Could this be a minor issue with the windows app?


(Tony Lewis) #2
  1. Yes ext to ext video will be coming soon. Video conferencing will follow that. No ETA on dates at this time that we can share with the public.

  2. You have to define your userman username @ your FQDN. You don’t use the extension number. Also you need to define your userman password. Lastly make sure your PBX has the ports opened on your firewalls for zulu to connect.

  3. I can’t think of any reason windows would take longer them Mac to setup a call.


(Ted) #3

I put this for the desktop app and it works
Ext@fqdn for the username
Password

The mobile app has a separate field for the server. I don’t understand why you would have to put different things on mobile vs desktop. Should just be all the same since it’s the same app.

Should i put ext@fqdn in the username field and fqdn again in the server field?


(Tony Lewis) #4

Your right for mobile we separate the two. Again the username has to be your userman username and password.


(Avayax) #5

That’s indeed somewhat confusing to the user.
I suggest you change that on the desktop client to match how you do it on the mobile app.


(Ted) #6

Well the desktop app actually has it much better! Just a one username string that includes everything with the server and just a field for password. Soo much better than the mobile app right now.

Both my username and ext number are just ext number in the pbx. Why not just leave login with one string.


(Tony Lewis) #7

Please feel free to open a feature request.


(Ted) #8

For now that i want to at least try the mobile app, would you guys be able to tell what exactly needs to be filled out in the mobile app account? I tried everything and it would not registered. And maybe put it in the wiki section.

Username -
Server -

The other fields i guess are pretty self explanatory.


(Avayax) #9

Do you have a valid ssl certificate configured in certificate manager?
On the mobile app you need your user manager username, password and FQDN that points your server.


(Ted) #10

Ugh, I don’t have the certificate working right now.
My certificate is not valid anymore and when I click to update it I get this error:

There was an error updating the certificate: Error ‘Token did not match’ when requesting http://my.pbx.com//.freepbx-known/6f6f6f40146fb2c437bf455e4fdc3194

Would you be able to figure out what the problem is?

And is it only the mobile app that requires the the certificate and not the desktop version?

Just a suggestion for the developers of Zulu, please don’t make things so complicated when it is a paid software. Make it work as it is one single unit, no matter what version it is, desktop or mobile. When you’re writing a wiki, sometime you can notice that it is written by an expert, that’s why they can miss a few things that should be included in the wiki.


(Avayax) #11

Is that a let’s encrypt certificate?


(Ted) #12

Yes it is.


(Avayax) #13

Is your PBX on a private LAN behind a NAT firewall?
If so do you have port 80 forwarded to your PBX and configured let’s encrypt to be present on port 80 under sysadmin/port management?
Do that and try if you can renew the certificate.


(Ted) #14

Wow, my LetsEncrypt section was completely disabled there. I put it to 80 and admin was put to 8080 like you have it. I was almost 100% sure it will fix the issue, but I still get the same exact error:/
I even opened port 80 in firewall completely for now.
What else could be the problem?


(Ted) #15

And my pbx is on a Vultr VPS right now. The certificate worked out of the box when I first installed the pbx.


(Avayax) #16

Can you install a new let’s encrypt certificate?
See if that works.


(Ted) #17

I get same exact error when trying to generate a new LetsEncrypt certificate

There was an error updating the certificate: Error ‘Token did not match’ when requesting http://my.pbx.com//.freepbx-known/2125499b81dc6e38c5269ee8d8b6d0b6

This is on FreePBX 14. My other FreePBX which is version 13 works great, I just updated the certificate on it by just clicking the update button. The configuration is the same on it. Except it doesn’t have the option to specifically assign port 80 for LetsEncrypt in port management. Where do you assign it in FreePBX 13?

Also could a problem be bacause of this strange double // after .com?


(Ted) #18

Also this is what I got from LetsEncrypt community forum

You should take this to community.freepbx.org . Whatever way FreePBX issues certificates, /.freepbx-known/ is not part of the Let’s Encrypt/ACME protocol, so it’s likely to be a FreePBX-specific issue.

You should ensure that http://pbx.mydomain.com actually points to your FreePBX instance and is accessible on the open internet (use only port 80, and ensure any AAAA/IPv6 addresses are actually reachable). Apart from that, there’s not much to go on and the knowledge to answer it probably isn’t on this forum.

I’ve always used my domain to reach the pbx and it has always worked.


(Ted) #19

Also since it says token did not match it probably means it is able to access the PBX through port 80 and compare the tokens right? Why would a token not match when it’s generated on the pbx and is then sent to LetsEncrypt and then sent back again. If LetsEncrypt couldn’t send it back to pbx would it generate a different message? Something like Could not access?


(Avayax) #20

I would try to create a new certificate with a different FQDN, to see if the same thing happens there.
You can grab a hostname at e.g. duckdns.org and have it point to the public IP address of your PBX.

Then use that hostname for your new certificate to try if you get the same error.