Vodia PBX

There are a few things you can do here. First of all, you should set the minimum TLS version to 1.2. This is actually required by most browsers today. The next thing you can do is to clear the ports for SIP/TCP and SIP/UDP. Then there will be no SIP without TLS. You might also clear the HTTP port and leave only the HTTPS port open. Same for LDAP and LDAPS. If you don't have the HTTP port available, you must use your own certificate (Lets Encrypt needs port 80 to be open). Alternatively you can leave HTTP port 80 open and set up the firewall to accept traffic only from the Lets Encrypt servers—though it remains a question what IP addresses it is coming from. As for SRTP, there are various settings for the devices that you use to enforce SRTP. E.g. you can use the snom General parameter to enforce SRTP. The apps all use SRTP and TLS anyway, there is not even an option to do it insecure. It will need some tinkering to make sure that everything really works, but at least you can rule out unencrypted traffic is on the server.

We have over the years constantly added features to the agent model. As far as I can see these are the differences between agents and regular extensions: Queues can play a hotchpotch of announcements to callers, send SMS to callers waiting There are various statistics available for the performance of agents and queues, online and by emails Call ratings from customers, and call categories from agents A new wallboard for full screen display Support for remote control of desktop phones (for superiors audio quality in call centers with professional headsets) Condition-based inclusion of additional resources, agents have control over "logging in" to individual queues Outbound calling from upload able call lists and other sources like missed calls Virtual hold for long waiting times Call position announcements and wait time estimates Handling in inbound text messages with agents Integration of mobile agents e.g. through condition based routing Management features like call recordings and call log reviews Automatic call recording and integration with third party call recording software (e.g. SIPREC) ... and more features will be added.

We are currently investigating issues with the caching with the Windows app and version 69. It seems to be working all fine from the browser (at least after you refresh the page), but in the app there seem to be inconsistencies. We might publish an updated version of the app shortly.

Hmm yes it should automatically set the DND flag. We tried this here and it did change. That area was unchanged between 68 and 69, however maybe the automatic reset of DND might be interfering?

The web item file is not empty, it just contains this skeleton. You can go ahead an put in there what ever you need. For changes in the common file it is preferable to use the Yealink general parameter, so that you don't have to modify the structure of the common file.

Looks like you are very close. But the provider is still returning "404 Not Found". Does the provider provide any examples? Maybe your phone number is in the wrong format, e.g. 2345678 instead of +342345678.

Should be available now.

Might have been a caching issue. The ringback melodies are internally more like images, that's why this is so weird. Anyhow, hopefully it's manageable now?

We have released version 69.0.4. This build includes a Windows 64 build again. The release notes are on doc.vodia.com. We still have to do a few changes to the MacOS app—you can use it however the login is clunky and does not take advantage of passkeys and the password reminder email. The iOS app should work well, and the Android version should also work fine with this version. The Windows app was already updated to take advantage of the new 69 features. There were several months between the 69.0.2 build and the 69.0.4 build; there were a few topics that just took a long time to get them done properly. We'll aim to have a 69.0.6 version ready in a few weeks (and we'll do 69.0.5 snapshots along the way). We do expect that we will still get feedback that will require some fine-tuning here and there but we are confident that 69 will be a great tool for office productivity.

Please check if you previously have turned on your own dictionary. If you have a dict.json file in your PBX directory, just more it out of the way and restart the service. If you are paying the same price for all extension types, then the agent extension type is no exception. Only if you want to benefit from lower price extension types, you'll have to accept the agent model as well.

Please make sure that you are on a recent version, e.g. 68.0.30 or 69.0.4. There was a glitch with enabling or disabling texting in a tenant. Or just explicitly set it in the tenant setting (reg_domains.htm).

There is no version 70 right now and nobody is working on it. 69.0.4 is the next release version (the builds have been made except Windows which hopefully happens the week). Every version goes through a maturing process, and as you can see 68.0.30 went through a lot of steps. I don't even think that 69 will need that many versions to reach a similar or even better stability as 68. We have a few systems in production already using 69 because of some new features that are not available in 68. I would dare to say that the underlying platform is now even more stable and performant than 68, but we all understand it take a little while until everybody fully agrees.

I assume these are not the real passwords... Anyhow you should see an error message like this on log live 4 for script: Unknown parameter ... for converting SMS URL, known parameters are: - {body}: The content of the message - {url}: A link to the message that is sent out (e.g. image) - {password}: The password for the provider - {param1}: General parameter 1 for the tenant - {param2}: General parameter 2 for the tenant - {param3}: General parameter 3 for the tenant - {address}: Primary tenant DNS address - {from}: The sender phone number in global format - {from-e164}: The sender phone number in E164 format - {to}: The receiver phone number in global format - {to-e164}: The receiver phone number in E164 format So it could look like: http://smsgw.gtsnetwork.cloud:80/message?user=aurelien&pass={password}&from=697677876&to={to-e164}&tag=GSM&text={body}&id=ID&dlrreq=DLR Please check what the ID and DLR values are for—you might have to replace them as well. Also, it is the best to have it working first with curl before putting this into your PBX.

We are working on a WhatsApp adaptor which should be available shortly.

You can just try to "hardcode" everything and then check the logs for more information. For example, the password will be available in the {password} placeholder.

Well for mobile, the refresh traffic should be really limited. The problem is that with all the go to sleep and wake up, it can be hard to figure out when it actually really need to refresh. The Vodia app is not the only one with the problem. Some other apps take an eternity to refresh data, at least the Vodia app is relatively fast (probably thanks to the backend).

This should be part of 68.0.30. There was definitely something fixed, is there anther problem?

That makes sense, we'll add another option that will change the host to the trunk domain name in the next version.

That is actually the default for version 69. We are trying to phase out the (at times, hard to understand) policy that manually started recordings end up in the mailbox.

The problem is that the replacement of IP addresses was not envisioned so far... We'll add it to the next 69 build. As a workaround you'll have to "hardcode" the actual WAN address there for now.

Well it is in the 69.0.3 build. However, the Fanvil model list has grown to a whopping number of 90 models. We will need some time to settle the dust for all those models, especially the automatic detection of the model.

Impossible is not a word in our dictionary.

It's really hard to tell if a person is available for a call, e.g. the PBX would wake up the mobile app anyway. An indicator would not have much value. We tried a few years ago when the company was still called pbxnsip to establish a simple standard for setting BLF lights, but it failed (sadly). As of today, when it comes to interoperability the "dialog-state" can set on, off and blinking and it is up to the phone to render it somehow. We try to use "blinking" as the promise that a call can be picked up, and "on" meaning that there is something like a call going on or at least the extension is otherwise busy (DND). For real information, the only way is to use the browser, where anything is possible.

The PBX uses some variables to insert the IP address pre-flight. This is because a SIP packet source address depends on the actual route which takes, so that you can use e.g. private IP addresses, VLAN IP addresses, VPN addresses, public addresses, IPv4 and IPv6 addresses all on the same server (many simple SIP servers don't do that). Anyhow as for the SIP trunk, there are other variables available, but they are not the same. As for trunk headers, the documentation shows what variables are available, but you can also see them listed on TRUNK log level 9 when you try this out.

... on a side note, we have introduced a setting for mobile client codecs in 69, so that a desktop phone can be on G711 and the mobile device on OPUS. Its all optional, but in most cases this makes sense.