Vodia PBX

There is no need to import the lets encrypt certificate - the PBX does it all by itself. Just enable it, make sure the domain name is resolvable through DNS and that port 80 is visible for the lets encrypt bot - then the rest is all handled automatically.

Yes please mail them to support at vodia.com

We have the FritzBox in the drop down for new SIP trunks. Did you find/try that? Also there are some tips at https://doc.vodia.com/node/189 (we need some screenshots to complete it)

You can use the "outbound proxy pattern" for this (in dom_settings.htm). There are some examples on https://doc.vodia.com/outbound_proxy that should be addressing your problem. There is a {if} statement that could in principle be used for these things like {if ip > "192.168.1.2" && ip < "192.168.2.255"} but currently that is not available. But it for sure does not hurt to add that possibility to the next version!

We have a load balancer that can do the job of inbound routing to the right domain (currently only for CentOS64 or Debian64). Inbound routing is either DID or domain-name based. You can use this also for routing outbound calls, so that all traffic to the SIP trunk provider goes through the load balancer. Contact sales to get more information.

If you automatically provision the desktop phone, the PBX will generate a MAC-dependent password for the VoIP phone. Then you can change the SIP password without any problems. If you use the SIP password also in the desktop phone, well then you need to change it there as well.

There is no way to find the password. It is generally considered a bad practice to find passwords, at least if they were entered by a human. You should instead create a new password. If you have lost the root password, you can reset the account from the file system. From there on you can always drill down on domain and user to overwrite passwords.

I would also test if the problem is related to the auto attendant or to audio in general. For example, does it work if you call the mailbox? Do internal calls work fine (which would point at the trunk and potentially at the firewall). You can generate PCAP traces from the PBX e.g. from the trunk; they usually help troubleshooting problems with RTP and media.

Ok the is the "complicated" case... There is some information on https://doc.vodia.com/failover on how the PBX can help you with the failover in that case. You could as well script this yourself, depending on how much time you can invest in understanding the hosting infrastructure. Especially the large hosting companies have powerful tools for handling such cases (including changing DNS records and notifying staff, creating newortual instances) that are better than what we have put into the PBX.

The easiest way to have a solid failover is to virtualize the PBX host. Then the hypervisor takes care about heart beat, periodic backup, going the IP address and what else is needed. With this it is possible to keep calls up in the case of a failover. Because the Vodia VM is relatively small, this can happen with less than 1000 ms. And there is no need to do anything with DNS. This works well if the failover is within the same datacenter. If you want to failover geographically between datacenter, then the PBX failover can be useful. The main point here is to make sure that you have a file system that is synchronized with the (private or public) cloud, so that you can start another instance when you have to.

If you are using a browser on your own server then you will see something like 127.0.0.1 or ::1. That is normal. Typically attacks come from some anonymous addresses, e.g. dark net and are physically far away.

Well that means someone was trying to log in - but did not have the right password. You can see from what IP address. This is a reminder to make sure that you have a reasonably good password on the server. If you like, you can also restrict from what IP addresses the admin can log in.

Where? User front end, app, emails?

We follow the idea that style should be in the CSS files and functionality should be in the JS files. The HTML should be the skeleton. There are always (hopefully small) exceptions, e.g. when it is just a lot easier to add dynamic content in JavaScript and include a class. There is a central CSS file that (in theory) should contain only the generic style information, and there are a few JS files that contain generic functionality e.g. how to format phone numbers. We don't encourage customers to change the JS files because that would usually cause just huge support efforts. The web server was not designed for frequent updates - that's why you need to tell the browser not to cache files when making changes. We know this when we make changes and it does not cause any problems once the browser stops caching things.

You can still just enter the setting URL manually into the phone, open the extension for provisioning and then manually reboot the phone. The setting URL would be just the address of the PBX, e.g. http://ip-adr.

You need to make sure that the browser really loads the CSS files - most browsers try to use the cache and don't even load the file if the name is the same. We include a version=xx in the name so that it will load the files after an upgrade, however that does not work if you modify the templates. One way to do this is to open the debugger and click on disable cache in the network section.

As far as I remember the network subsystem in that version could run out of resources. I would upgrade that system - this should solve that problem.

Yea is seems that this file is not on Windows 10 any more - we might have to include this in the .xml file for download. Might be a bit of a problem as MS probably does not update it any more.

snom 821 might be a problem because the phones are not able to store the firmware - it runs out of memory. We believe that this is a phone problem that we cannot solve (the phone was introduced 10 years ago in the market, so it might be understandable there might be no more updated firmware available). 765 is newer - the SW update should work better there...

Added some more information to the page - about what file name you need to put in there to make the provisioning magic work.

Yes you can provision those devices. Did you see the information on https://doc.vodia.com/provisioning_panasonic_phones ? "However because by default the phones don't have their web server enabled, this requires a manual enabling of the web server." - so I would try to provision them first in the LAN - then you can see what provisioning URL was set in case you want to use them for hosted PBX. it is not as convenient as modern models, but should work nevertheless.

For that (and for many other occurrences) you should give it a name that is DNS resolvable. It is okay to keep the short name as alias, but the primary name should be the "long" DNS name.

The \* means match a * character. So this pattern would match e.g. 9*1234. Usually you don't need those complex (and powerful) "extended regular expression", simple expressions do 99 % of the job...

Well the PBX checks at midnight if any of the certificates need to be renewed. If you can wait until morning it should heal itself.

You can use service flags to control which WAV is being played. Maybe that helps?