Vodia PBX

There is no hardcoded limit. 1 MM records should be no big deal for a regular server, but you can also make to 2 MM or 10 MM if you like. It will just take up more space on the hard drive and also in RAM, though we try to keep the memory part small. Also it will make the restart slower because the PBX has to read the index files before it gets operational. For each tenant there is a retention period, which serves as additional limit. Typically the tenant limitation should be the one that really limits it. If you promise tenants to keep the records for a year then you want to make sure that the number of total records in the system is far more than you would expect from that tenant. Some Vodia partners have written external CDR storage solutions. For example the PBX can push records straight into MongoDB. However (at this point) it's a one-way ticket from the PBX point of view.

Its a moving target... We are trying to make it better in every version, but obviously it's hard not to trip over anything. Plus the phone vendors are also upgrading their firmware. But while VoIP phones seem to use SNI on HTTPS, it is mostly not enabled on SIPS. If they do, we are enabling it in the template. That was also a little bit of a learning curve. For prepaid licenses we are trying to ignore it, for postpaid the agent type is more than the Teams extension type. So the "all functions" would be the agent at this point. This was causing the problem that agents now includes Teams, which was causing a headache because of the inclusion of Teams in agent queues. Anyhow, as of 69.1.1 it should be working smooth. But we will eventually have to check if we still have to adjust this.

There are no hardcoded limits in the PBX executable. We have systems with more than 10K extensions (but low call volume) that work well. The limiting factor is how much traffic and calls the CPU can handle.

This is because of the setting "Ignore packets that do not match a domain on the system" (in /reg_security.htm). It's a good idea to have that turned on. There are two things you can do here. First, you can use the system management DNS address as a fallback address for devices that don't support the TLS SNI extension. Second, if that is not possible, you can set the setting sni_sip_ldap to true, this will override the "ignore packets..." for SIP and LDAP. Oh and you should reprovision your phones. The templates should automatically set everything right.

There is now 69.1.1 available including Windows and a new iOS build needed for the new chat history elements.

Did you try to use the integrations framework?

A common pitfall is to enable "VIP" permission to an extension to hide the CDR in the group. Then the PBX does not keep those CDR.

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?