Vodia PBX

Oh wow we were not aware about buttons on that device... Can you open a ticket and attach the XML config export and we'll take a look?

We still don't have usage data for SMS. How are you billing for call minutes? Are you using the rate tables? Would this be a way to add it to the bill?

This should not be related to the group permission. I think the easiest way to experiment is to use a service flag and assign it to the extension (is in the redirection settings on admin level right under the DND setting, "Classroom DND control"). Otherwise you'll have to midnight to see any change.

You can see the MOS for a trunk in the page for the statistics for the trunk. Same for each extension. But I agree it can take some time to find the exact call that was causing the problem. At least there is some kind of hint. MOS scores are a little confusing because their range is between 1 and 5. There is no MOS 0. If the MOS is 0 that is more like a hint that there was simply no information about a MOS. For example, there was no call or at least no media.

We made some progress. This will be pretty much another SMS provider. You'll have to create an App on the Facebook App Store and point the incoming messages to the PBX. The format of the messages will be similar to what other SMS providers are delivering, but all in all it will follow the same script.

We made that a priority ten years ago, e.g. added a feature so that secure calls can also be terminated over a seemingly insecure SIP trunk. For example when a PSTN gateway is connected through its own Ethernet cable to the PBX, this could be deemed secure. But the feedback was a little disappointment, in a nutshell nobody cared. The solution to disable all non-secure ports and force the phones to use SRTP through a general parameter seems like a workable solution for now. We don't have to change anything in the PBX, and this is an easy parameter setup that should address your requirements.

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.