Jump to content
Vodia PBX forum

Vodia PBX

Administrators
  • Content Count

    9,681
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Vodia PBX

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male

Recent Profile Visitors

192,319 profile views
  1. 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.
  2. Yes please mail them to support at vodia.com
  3. 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)
  4. 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!
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. Where? User front end, app, emails?
  14. 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.
  15. 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.
×
×
  • Create New...