Vodia PBX

Looks like the Windows phone to me.

Is it ringing for the ring duration and then eventually accepting the call? You can try to set the ring duration e.g. to 5 seconds. We have found this recently and will provide a fix soon.

We went ahead and made version 66.0 publicly available. The release notes are at https://doc.vodia.com/releasenotes660. We will also send a newsletter about this update out. We'll likely make another build for the .dat file in two days which will contains some additional features for the handling of transfer calls on the web frontend, but this is not critical at this point. If you want your users to use the iOS 1.5 app, we strongly suggest to upgrade to this version as it comes with a few necessary new API calls to make call hold and transfer possible. So far we have made only the 64 bit builds—please let us know if you are still using 32-bit versions. It would be great if we can eventually phase them out.

The 32-bit version is not available right now. Is there any way you can use the 64 bit version?

Can you also check if the phone left any "traces" (log level 9 for provisioning and maybe even the web server) after a reboot? And is there anything useful in the log of the phone right after the reboot? E.g. would the phone trust the PBX web server certificate?

Some phones have a built-in PCAP recording feature. This can help a lot troubleshooting multicast problems.

Well it is not released yet...

If all handsets support multicast paging, I would also consider using the multicast mode. Otherwise the PBX needs to call up each extension and put them into intercom mode (this is called unicast mode).

There is a password policy for the server. This determined if a password is considered to be "secure" or not. Especially when running the PBX on a public IP, it is important to make sure that the users have reasonable safe passwords for their accounts.

That means that the HTTP password is not secure.

You can also install the PBX "manually" using the sc command (see https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/sc-create). In that case all you need is to download the pbxctrl.exe and pbxctrl.dat file, put it into a directory of your choice and then use sc to start it as a service.

We have made a new installer (see https://doc.vodia.com/install_win) that is using the latest Windows for the build.

The problem is usually that one side proposes optional SRTP and then the other side answers without it, leading to a "one-way" SRTP encryption. If you want to keep the old version you might have to go back to TCP (I would not go to UDP because of the UDP fragmentation problem). I don't think the upgrade will make any difference with the certificate. The old snom models did not check the certificate dates anyway.

Thats most likely because the SRTP key negotiation failed. You can just manually disable SRTP in the phones to fix the problems. Or upgrade to a recent version of the PBX.

Well, this is not a straightforward case. There could be problems with the codec negotiation and it might require a re-INVITE (need to put the call on hold and resume) to see something.

My guess would be that the network is not ready in the early stages of the boot up. However that would not explain why a call gets rejected—especially because obviously the TSP does receive traffic from the PBX so that cannot be the problem. In order to solve the problem there are essentially three paths: The first one would be to back and forth and try to resolve the problem in a Windows 10 system. We could install the ephone.exe and try to reproduce the problem in a debug environment and then make changes to the TSP. Unfortunately debugging TSP is not as straightforward as debugging other programs (TAPI is a very old Microsoft technology; I am not even sure if the latest Visual Studio can still compile the code). What speaks for this solution is that there are still a lot of people out there using TAPI. The second would be to try to avoid TAPI and instead talk to the CRM directly. For that the question is what CRM this is and if they have a API, ideally a REST API. This would make it possible to look into more features and make the installation of other systems easier. The third would be to just use Windows 7 or find some registry entries that make Windows 10 behave like Windows 7 in the TAPI subsystem. This would be obviously the least desirable solution.

The trace is very useful. For whatever reason the TAPI subsystem decides to reject the call (see https://docs.microsoft.com/en-us/windows/win32/api/tspi/nf-tspi-tspi_lineclosecall). What I would try is installing it on another system, maybe an older operating system where we can be sure no process is interested in incoming calls except e.g. Outlook. Maybe on this system there is something else trying to consume incoming calls and this is causing the issue.

Typically this is is because you have a lot of CDR records. We have speed up the reading of the tables a lot in the later versions—though there will be a one-time migration that will take a similar time. What you can also do is to reduce the duration how long the PBX keeps the records. This will gradually reduce the number of records. To be sure what the problem is I would check the sizes of the directories in the working directory of the PBX.

Right now we don't have stats for that. There might be some information on your SMS provider side.

Depending on your country code, the pattern would be 01132* (+32 only if you set that in the dial plan) and the replacement then would be 01132* as well.

You can send internal messages between users and you can also send external messages (SMS and MMS). The support on the app is best on the Browser/Windows app, available on the Android app and "in the works" on the iOS app. External messages require that your service provider supports SMS/MMS. The list of supported service providers is currently small; but we are working on extending the list.

If your PBX is behind NAT, the refresh time might be too short. Some providers expect that the SIP client refreshes the connection every 30 seconds, even if they say every hour.

Are you on version 1.4 of the iOS app? Also are you on a recent version of the PBX (e.g. 65.0.10)? The new version support support a fast app start, which should make sure that only a few messages are exchanged to answer the call.

The app probably has problems getting to the PBX. When you generate the QR-code, you should do from a browser that is coming from a similar location like the phone. In other words, if you use "localhost" the phone might have problems finding the PBX. Ideally, you should use a DNS address for the domain that has a certificate. If you have a certificate, make sure that you are using the https scheme for the URL.

If the app shows the extensions in the domain on the home screen, that means that it can talk to the PBX. If not I would check the certificate (if you are on public IP, using letsencrypt should be easy) and what URL was provisioned into the app (click on the account name to check the settings). If that works, only the firewall could be blocking RTP. I would check first if you can make an outbound call before receiving a call. This also makes sure that the app has the microphone permission which sometimes is invisible if you accept the call from the iOS incoming call dialog.