Vodia PBX

Yes, and some partners have modified the user front end already. But we want to offer a better solution once the functionality dust has settled a little where the user can arrange the screen as needed.

Theoretically possible, but unlikely. Maybe you can open a ticket with the PCAP attached (don't wait ten minutes) and we can take a look if the sender was supposed to hang up or something else failed.

If you don't see the texts, check if you have switched to on your own translation (pbxaui/dict.json) and consider removing the file. The tab contains general settings for the queues, e.g. a table with wrap-up-codes.

It will be backwards compatible.

Yes you can drag the call across the page into an orbit. If that's too far, you can also just use the pop-up and enter the park orbit number there and transfer the call into the park orbit that way.

Ok for inbound calls, you can always use the "destination for incoming calls" in the trunk to set up complex rules. For example, if you want to accept only numbers ending in 23 and we and send them to 23 or 24, otherwise to 0 as a default. Extended regular expressions are cryptical but powerful and you should be able to do anything you need with it.

You can use this link for now: http://portal.vodia.com/downloads/pbx/version-69.1.xml we'll update the links soon.

VM = virtual machine? If you sent out the IP address as the provisioning address for the phones, you could use the RPS to set the new address. If that's the problem, is there an option to use your previous IP address? Otherwise it might get ugly and you would have to get into each phone and set the provisioning address manually again.

In the dial plan, you could use "route internal calls" (or not) to address this problem.

We have made builds for 69.1. Windows and the Vodia IO builds is lagging a few days behind, but the other OS are ready. The release notes are also ready. As you can tell by the name, we are confident this is a major leap forward. We have worked hard on making this version very stable and more scalable than ever. There are a lot of things under the hood that should keep us out of trouble for the next years: We have redesigned the threading, which should dramatically reduce race conditions that can cause hard to find and frustrating bugs on so many complex systems. It also improves the performance of the system. Memory allocation should be more efficient. This means the server needs less RAM than before for performing the same tasks. On the security side, passkeys make it impossible to steal passwords from the system which might be important in the upcoming years from compliance point of view. We really want to get away from users entering passwords, because this puts the burden of keeping those passwords safe on the system. We started supporting EC-based certificates, however this needs to be explicitly be enabled. We will see if those certificates break TLS with older phones that don't support those certificates yet. We added might insights into the behavior of the SBC. Connections are now logged by default for the past 24 hours, making it easier to locate clients that need to be permanently blocked. We have added something for better handling large recordings. Even when recordings are several hours long, the PBX can handle those large files better than before. We have added FAX ECM mode for T38. We tested sending large documents without transmission failures. We will add this also for the inbound "analog" FAX and for outbound FAX soon. But also on the more user-visible there are some important features available: Users can now start calls with video. This does not only work between desktop phones, it also works between the browser and Vodia desktop apps. We have worked on the quality of the queue reporting and added some more popular metrics. Text conversions now include voicemail messages and call logs. There were several topics on this forum regarding improvements with the user front end. It's clear that the user frontend will keep us busy for years — just another reason to make sure that the underlying PBX subsystem is solid. We will have to release a new iOS version soon because of the changes in the text. We also have an updated Windows version in the pipeline that will take advantage of version 69.1.

Skip to 69.1...

We have 69.1 for MacOS.

Is the provisioning address on the Yealink set correctly? Or maybe do you have option 66 in the LAN interfering with the provisioning setup? Does it provision after a hard reboot? I would definitively stay away from setting the config on the phone web interface, this will become a nuisance over the years of operation. It would be possible to remotely make the phones fetch the provisioning data, this will make your life so much easier.

In theory this should be just another gateway. If you are using port forwarding, it would be important that the gateway does not bypass the port forward and present a different port. This would confuse the PBX and explain why it behaves erratic. I would actually try to set it up without port forward and just keep the registration interval short enough to keep the NAT connection alive. If the gateway supports TCP or TLS, that would be preferable so that it would be obvious if the connection is alive.

We did not have them in our lab. The question is how similar are they with the desktop phones?

I would turn logging on and see how the call gets though the various stages. Maybe the problem is that the number companion fails, maybe because the address book entry starts with plus while the trunk was setup not to convert the number into this format. Underneath calls are considered SPAM, which does not necessarily reject the call, e.g. route it to the mailbox instead. Anyhow, the log should show more information. Also, what version are you on.

So when 69 starts up, it checks if there is at least one group where all extensions are members. If that is not the case, it creates one. Then when running and a permission is needed, it goes through the groups where the account is a member and checks if at least one of the groups has that permission. We have added a setting to 68 which behaves in a similar way, but it needs to be explicitly enabled (set grpdef to add). Yes the scrolling is annoying. We are trying to find a solution.

If in 68 there was a group that applies to all members then the PBX will not generate an additional default group. Is that okay?

No problem. Right now we do these roadmap discussions in 1:1 meetings which are very productive. However we might need to schedule a different format which is more for the public, e.g. a webinar or some pre-release notes.

There is a roadmap and there are no big surprises on it, however this is not the right format to discuss it.

The # key is generally seen as confirmation key. In the auto attendant, it is also used for triggering timeouts (as if the user has pressed the enter key after nothing happens). In theory you might be able to use it in the direct destination area, but it would not read out the prompt to repeat the options.

Still a mystery. Can you private message the path to the welcome.htm?

As a workaround for now, you can just blind transfer the call through the pop-up on the call.

The thing is that it seems to work in our environments without the data... Anything in the inspector regarding code that does not come from the PBX?

Yes an obvious fix would be to add blob: to it (or data?). However it should not use data. I am wondering what is triggering it to use data... It should not do that unless there are some obscure libraries at work...