Vodia PBX

Use country codes, then the PBX will present the numbers in "human readable" form. Many devices have problems dialing anything else than 0-9.

Not bring the biggest expert on this, my understanding is that the virtualization layer itself is not that expensive any more these days, as the CPU has special components for virtualization (e.g. see http://virtualization24x7.blogspot.com/2015/04/hardware-assisted-cpu-mmu-virtualization.html).Obviously you need to double check that your server supports those extensions, but my guess is that this pretty much mainstream these days. One important thing about the PBX is to be able to provide CPU resources very fast, e.g. when a RTP is knocking on the door. The simplest approach is to have only one VM on a physical CPU, then there will be no doubt that if the PBX gets the CPU when it needs it. If you have this kind of load, it makes sense to reserve one CPU exclusively for the VM. Also the network subsystem should be able to deal with virtualization. The server will have to listen to a bunch of MAC addresses. If the network adapter has to go into promiscuous mode, it means that every single packet will interrupt the CPU. Again without being an expert, I would assume that there must be some kind of hardware acceleration available also for the network side that triggers an event only if there is something really available. If you have 100 calls, there will be 10000 packets flooding the server per second; if that all has to be emulated in software it will drain some significant resources. Maybe it makes sense to post the question also on a forum that deals only with virtualization.

Ok, the solution is to leave this question to the operator... There is a setting called "rest_show_passwords" in the pbx.xml; if you set it to "true", you can get them with /rest/domain/<domain>/user_settings/<account>. Default is not to show the passwords.

Providing the password is not a good idea. If the admin account leaks out this would be a easy way to get all the passwords. An alternative would be to set the password (overwrite it).

Anything in the JavaScript console.

Yes that is what we tried. Worked like a charm... Using HTTPS (without a valid certificate), though.

GAPS with snom? You mean GAPS with Grandstream? We have added that, however it is kind of hard to use because the devices first have to be assigned to the reseller on the GAPS side which kills the purpose. We are working on a change that uses a special GAPS feature to avoid that.

Ok updated to Safari 10.0.1. Where is the problem again? Clicked through a couple of trunk pages for setup, it all worked as expected...

My guess is that there is something wrong with SRTP. Did you automatically provision the phone? If that is the case, change the transport layer for that extension to TCP, re-provision it again. Or just go to the web interface of the phone and change it there. And I would also make a PCAP trace from the web interface of the PBX for that extension. Then you can see what the PBX was able to decode in the RTP stream.

We will update ASAP.

We tried that here with Safari 9.0.3, could not see any problem. Were using HTTPS, not sure if that would make any difference.

In the generated folder, there is a "history" file, that one shows you when what file was generated. If the PBX generated files after it was rebooted, then it is a good sign that the provisioning worked fine. To open the phone up for provisioning (this is like "pairing" in WiFi) go into the domain, then click on extensions, select the extension that you would like to pair, and then select the open up option in the select box at the bottom right of the page. The provisioning is not related to the cell phone. The question is if the phone was registered successfully; if not this might trigger calling the cell phone. The seTinGs UrL iS cASe sEnSitIVe. Please just use "https://192.168.254.200"(or "http://192.168.254.200/prov/snom320.htm" see https://vodia.com/doc/pnp_snom). The reason why the phones take a long time until they finally start working may be that they perform a software upgrade. If the Internet connection is slow or the phones cannot reach it all, that might be the reason why they are just sitting there.

Most phones today do the provisioning in the background, so that even if it should take an hour to figure out what configuration to use, the user would not be aware about it. Of course it does not take the PBX an hour or even 40 minutes to generate the configuration information on the fly, so there must be something else going on. A couple of things that you can check quickly: Does the PBX put anything in the the "generated" folder for that extension? Did you open up the extension up for provisioning on the PBX web interface (domain account overview) ? Do you see any log messages in the PBX (TFTP and PnP log level set to 9)? If there is no trace of the phone on the PBX, there is probably a problem with the phone finding the PBX. Here you can check: Did you set up the "settings URL" on the phone? Are you using option 66 on your DHCP server? What you can also do is to factory reset the phone, reboot and then you should find it in the PBX web interface for LAN provisioning phones, where you can assign it to a domain and to an extension.

Not sure at this point. Sounds almost too good to be true! If I get this right, this should massively shake up the certificate issue industry?

In the agent group, the announcement "0" is played always in the beginning, even if there is nobody else waiting. This announcement is good for informing the caller. The other announcements are played in a round robin fashion. In principle they could be played in a random fashion as there is no guarantee that they will occur at all, but right now it starts with the first index "1".

I tried to find something in the internet, it seems that shoutcast is using its own protocol (which we don't support). Maybe VLC can take it and turn it into a RTP stream, which then can be sent to the PBX for MoH.

When you log in, make sure to enter the domain name in the browser, so that the Host header of the HTTP request tells the PBX what domain context to use. Obviously that requires that you have set up the DNS accordingly. Then you can just login with the username, no @ required. More information on https://vodia.com/doc/login

OK check out https://vodia.com/doc/shellscripts

Looks actually quite interesting and it would solve problems that we have with many deployments. We need to put that somehow on our list.

Would a shell script help? It should not be too hard to go through the macs table and present that information for you.

We have released version 56.0. There were some hiccups with the .dat file, but they should be resolved now. Please check the release notes at https://vodia.com/documentation/releasenotes560 where you can also find the link for the upgrade.

There is a setting "Call cell phone when new message arrives" that has settings how long the PBX should wait before it calls the cell phone. It will try to call that phone 3 times I believe.

It is now available at http://vodia.com/downloads/pbx/version-5.5.6.xml

There is nothing that would explain why a different license would change the behavior. Must be something in the setup, maybe the network environment or a different service provider. A PCAP trace would show there the problem is. I suggest you open a ticket with the PCAP attached...

You probably need to "open the account up for provisioning" in the extensions list. Then there is a time-window when the phone can fetch the configuration data from the PBX without having a password yet. It is a little bit like Bluetooth or Wifi pairing.