Vodia PBX

If I remember correctly having an application start after login in Windows is easy, maybe there is a way to set this programmatically and if that is so, we should do that along with the close/minimize button.

Its included in the latest build for 67.1. It is good for trying out the FAX topic, but there are a few other topics in that build that require attention before we can release it.

Not really, but it is also very annoying when debugging...

There is some info on https://doc.vodia.com/docs/appearance on how you can drop the logo into the file system, then it will override the built-in logo. For new installations you can just copy the content of the pbxwebai directory to clone to customization, this is usually much faster than going into the web interface and doing it from there.

There are limits of what we can do because of the various app stores. For example, we tried to change the logo for the Android app and Google took the app down because we were seen as "imposer". The road to go is to do co-branding, so that the logo appears inside the app, similar to what we already do on the web front end. Most customers are perfectly okay with it, it's similar to the experience on the desktop phone. The plastic has the manufacturers name printed on it and the display shows the company logo.

Its in beta now (67.1).

There are a lot of conferencing solutions available that might fit customers need and budget. If you want to host it yourself, you could use https://jitsi.org (some of the competitors just white label and sell it as part of their solution). If you don't want to host it yourself and your clients have Google accounts, you can also just use Google Meet. Then there is Zoom, Teams, WebEx and a lot more. It will be hard for a PBX manufacturer like Vodia to compete with these solutions like it is hard to compete with CRM solution providers. 1:1 video is much easier and we will see this soon in the app.

It says "Receive SMS" so it did receive the SMS. Try to turn on the log level for "script" to 9 to see more information. I guess you have selected a SMS provider already? Also turn the log level for "IVR events" to 9 (yes that log level is quite misleading).

I remember there was a post about this a few weeks ago, but this should be in the latest (which is 67.0.2 at the moment).

That is a well known problem. When the PBX sends the CANCEL message to the phone, this is the only way it can tell the phone wether the call was missed or not. There is no way to tell the phone later that the call was missed. There is a flag on each stage of the hunt group if the PBX should do it or not. In doubt select "no" so that users are not calling the same number multiple times back. When the hunt group reaches the final stage, it can send an email. This would be the proper definition of the missed call. For example, if you send the email to a email group, then you can have the employees work out who should call back.

It should be fixed in 67.0.1, it was simply because we usually test it coming from the admin mode where this problem was invisible.

That should also work. Many people are using standard SMTP servers — its actually usually easier than gmail.

Its complicated. Keep in mind that many installations are still on premise where there is no (real) HTTPS. "Automatic" will check if there is a certificate for a domain or the server management address, and it that is the case it will do the redirect. If you are running the PBX on a public IP, you might want to rename (or just remove it) the localhost domain so that the PBX knows it has not to serve all incoming requests, which is another challenge for presenting a valid certificate.

IMHO if you control your own CRM code, I would rather go for the integration that requires those changes on the backend (see https://doc.vodia.com/click2dial "Click-to-dial Embedded into HTML"). Then when the user has logged into the CRM system, there is no need to enter a password. All the user needs to do is click on the phone number that you present to the browser. The user can also disconnect the call from there.

Well you can start calls only if you have the password. Otherwise you will soon have a lot of calls on your server, especially if you are running it on a public IP!

The problem for the PBX is to tell what URL to use. When you are logging in with the browser, the PBX says "oh good, this one is able to see my page so lets use that page". If you are logged in with HTTPS well then that's a good sign. Even when you trigger sending out an email from the web interface, the PBX tries to use the address that you entered in your browser to generate the URL. So the bottom line is, don't log in with the IP address in your browser or an insecure connection. Needless to say, make sure that the domain has the green lock symbol indicating that the browser thinks that the connection is secure—that usually means that the app also believes it is secure. iOS and Android are these days very rejective to insecure connections.

In the next version (67.1 and later) you can use the form validation for December 31 to see if you enter it the right way. Internally it will be represented as YYYYMMDD, so you could grep in the file system in the service flag to see what was actually stored. Yes you can include a time in a service flag. For example 12/24;2P would mean (in US locale) 2PM on December 24. Your example should be "19/03/2021;17:00-22/03/2021;09:00" and in the 67.0 notation "19.03.2021;17:00-22.03.2021;09:00"

It is confusing. The only way to get out of this is to choose internally a format like YYYYMMDD and then have the front end handle it based on the locale. YYYY-MM-DD is not possible because we also support date ranges that use the hyphen between the dates. Lets try guessing the locale and re-format it internally to YYYYMMDD in the 67.1 build.

Oh, you need to enter the date as "5.3.2021" — this is the sign that the format is DD.MM.YYYY. If you use slashes, the PBX assumes the format MM/DD/YYYY. You can actually try to enter January 31, the form validation will reject the wrong format then.

The hunt group is a lot more complex than directly calling an extension. E.g. when moving from one stage to another, the cell phone timeout from the previous stage could be still pending. Regardless of the delayed cell phone call issue, because of the nature of the hunt group, multiple users are getting the cell phone call and compete for the "1" press — with the result that some of then will not get it. This is not the kind user experience that I would expect in the year 2021. Apart from the problems with the presentation of the caller-ID. We had this feature for 10 years when back then PBX apps were clearly bleeding edge of technology and using GSM was a good answer to QoS problems. IMHO today most of the users could as well just use the app and get the call directly, with Caller-ID and everything, no transcoding, on their device instead of routing it trough the PSTN.

You are absolutely right. The password is another exception to the rule that parameters can occur only once! It might have made sense to call the parameter security.user_password.admin, however we are not going to change the Yealink provisioning names. We already had the exception that if the parameter occurs just in the line before it would not be considered a duplicate. Anyhow this will be fixed in the next build which is 67.0.2.

We actually tested it here and it did seem to work... Is the problem the form validation in the browser or does the service flag not show the right status?

Doing the delay in the hunt group makes things quite complicated, e.g. because agents can be in multiple stages. IMHO for heavy usage, it makes more sense to give them the app and use the mobile phone "natively" instead of using GSM.

If you set the domain provisioning password again, does it work then? We have heard that the migration of the password was not always working from the previous version to 67.0.

We had addressed that in later versions (after October 2020). What version are you on right now?