Vodia PBX

The pbxctrl.dat contains the templates for the web server, emails, image and configuration files like the ringback.xml. Essentially this is everything not generated by the compiler. We started compressing it some versions ago because the Vodia IO does not have too much hard drive space. It should be the same version like the pbx executable; just treat it like a DLL. We had that button for downloading everything in older versions - however it turned out to be a support problem because systems grow and when you download a Gigabyte, it crashes the browser and it also crashed the PBX web server. Especially restoring backups was a major problem. That is where file system is a lot easier and faster.

Yes it is actually very simple. Everything is in the working directory of the PBX, with a few exception and notes: If you set absolute paths, e.g. for the recording directory they are obviously not necessarily in that working directory. The configuration file for the fail over itself is usually not in the working directory. Even the executable is part of the working directory. That means if you do a snapshot, it contains the exact version that was running at the time. The file contents are independent from the operating system. You can move a installation from Windows to Linux if you want. Exceptions are the executable itself. For backup that means, you can use e.g. Dropbox or the Windows backup mechanism to automatically make backup off the physical server. Those backups may even be historically, which means if you screw something up you can go back in time and restore a certain state at a given time. The good old file system can be very powerful!

Yea... another common problem was that the previous default number of connections was just 50, which is very low. You should set that to 500 or even more (/reg_ports.htm). As for the login we have a secondary login page "rawlogin.htm" - you are not the first with that problem!

After you change the domain provisioning password, you need to re-provision the phones. You can do this through the web interface, in the extension list.

If you want to log in to the web interface of the phone, you need to set and use the domain provisioning password (/dom_settings.htm). By default, this is a random password - yes it is not easy to guess

Looks to me like the PBX could not open the sockets for HTTP/HTTPS. Maybe the firewall does not like the new executable? What OS is that? Check with netstat is the ports were opened.

Every phone has a different place to enter the SIP password for an account. Generally I would recommend to use the automatic provisioning for VoIP phones. There are many other settings that should be set, it is very difficult to do that manually. And the PBX is automatically assigning a password to the VoIP phone which is different from the SIP password (every extension has many passwords).

You don't need STUN. The SBC does take care about this. Please see https://doc.vodia.com/server_behind_nat for some basic information about how to run a server behind NAT - this is called "near end" SBC.

You would have to enter a new password. In the IT world it is generally a bad idea to show passwords. It might be even against GDPR to show e.g. a user password to the administrator. Look at all the news about facebook leaking passwords!

System management DNS address has nothing to do with NTP. Maybe the problem went away because of some other change.

Grandstream has a lot of different devices, with a lot of different firmware and a lot of different settings names ("Pxxx"). For the LAN provisioning maybe there is something different with their web server. We will have to check this here. The solution is to log into the web interface of the phone and manually set the address of the PBX (see https://doc.vodia.com/pnp_grandstream) in the setting "Config Server Path" - and make sure that the extension 203 is opened for MAC-based provisioning.

NTP does not tell the phone what time zone it is in. This is done using the phone provisioning. For setting the NTP server, there are two things you can do here. Pick a NTP port (e.g. 8232) so that the PBX will provide the NTP service (not sure but this might require a restart of the PBX service) and then re-provision the phone. Obviously then you must make sure that the PBX has the correct time. Or make sure that the phone can reach the NTP server on public Internet. You can also choose another server, e.g. pool.ntp.org. Maybe your firewall is blocking that kind of traffic. You can also check on the phone if it was able to resolve the DNS address (snom phones show you the content of the DNS server).

When you provision the phone for the first time, it sets the address for the PBX - including the port number. If you change the port number, well, it will become unavailable. What you can do is to keep the old port open (e.g. use "8080 80" in the HTTP port settings). You can change the templates from the web interface (/reg_texts.htm): You can do this on system, domain and extension level. But usually you don't have to do that, just set the general parameter for the phones (reg_pnpparm.htm). When you change buttons the PBX automatically sends a re-provision request to the phone. You can manually trigger that by going to the registration tab for the extension (dom_ext3.htm) and there click on the re-provision or the reboot button for the registration.

What you could try to do is to set the "Label template for private lines" from "{user} {name}" to "", so that the label sent to the phone is empty:

Yes if you want you can try the 63.0.2 build available for CentOS64 and Debian64.

Did you set the country code for the domain, so that the PBX can automatically convert the numbers into the same format?

You find that on https://doc.vodia.com/releasenotes - the IOP were produced on a version that did not list the available options yet. The newer version show you right in the update page what is available.

Its clear where the message is being generated, but not clear why there is now a list... It will take a few more days to figure that out.

Next training will be in Texas - if you like we can share the slides with you.

The scope would be within the ACD, not on domain level but it would send calls away if there is anybody else in the ACD. Maybe you can elaborate a little bit more on the use case, and then we can take a look what we can do to get as close a possible.

Do you have a frame so that we can say exactly where the problem is?

You can do this in the ACD - there is a setting on how many calls may be in the ACD and then redirect the number. But for the auto attendant there is no such setting.

You can limit the number of calls in the domain settings on system level. Would that work?

We had G.722 support for a long time. My estimation is that less than 0.01 percent of the calls were using it, even though most phones support it. There are a few things to keep in mind here. First of all, we have to keep in mind that every kind of transcoding reduces quality. Audio quality never goes up, even when using a great codec. If you are on Opus and then the call gets transcoded to G711, it sounds not as good as everybody using G711. That being said, there are very few (no?) SIP trunk providers that offer anything better than G.711. Internal calls may have great quality. The problem is that they are usually not the call generating revenue in businesses. Most modern HD codecs were written for client devices, meaning that CPU usage is not a big deal. However when you want to have 500 calls going on in the PBX, it is a big deal. It is debatable, but IMHO there is a certain user expectation about how a office phone system should sound like. When IVR sounds narrow band, callers have that warm fuzzy feeling they are talking to their good old (and reliable) phone system. From a sales point of view, Opus and HD are indeed a great way to wow new customers. That is currently probably the most important point. We have added Opus to the development branch, however this needs to be tested first and made sure that it does not cause any harm. We need to change the default priority of the codecs and put HD first. Otherwise nobody will ever experience HD audio on the Vodia PBX. We found only a few Cisco and Polycom models support it today. Its a chicken egg problem obviously, and the PBX should take the first step.

translation.txt