Vodia PBX

We have added that in 68.0.14, however in the 68 version this will only work for manual service flags. We have made some changes to the way the automatic service flags work, and in the next version 69 automatic service flags will also show up in the app.

Our current understanding is that if you want to use the iPhone address book, well then you should use the iPhone address book app. There you can decide on how you want to call a contact — it is a little tricky b because you have to press and hold the call button, which will open a dialog where you can select "phone system" for making the call. You can even define for each contact what your preference is for calling that contact. This works similar in the iPhone call history where you can for example call back a number with the same app as it came it. This works well for the native phone, but also for any other app that uses CallKit. The bigger picture is that as a company you would prefer that employees don't store business contacts in their private address book. I know this is debatable and we might add that possibility in the future, but would probably leave it to the PBX admin to allow that or not.

For proper inbound routing, you need to assign the SMS number either to one extension or to one call queue. In the case of extension, the routing is always clear. For queues, things get more difficult because agents can be available for chat or not. If there was a previous chat with the external number and the agent is available for chat then an incoming message will be routed to that agent, so that there is a continuous chat possible. Otherwise the PBX will find an agent that is available for chat and assign the chat to that person. If there is nobody available the PBX will send out an email, so that a manager can be notified that a chat message was not received by any agent.

The SMS routing is different than the call routing. Right now you can route a SMS either to the extension (through the extensions SMS ANI) or to an agent group. In an agent group, because agents can be logged in or not, things can get confusing when a message is received. The idea is that they work as a team and take over the conversation with a specific number, including the chat history. What link did you use for the 68.0.14 version?

TLS 1.0 and TLS 1.1 are increasingly seen as security risks, and so they should be turned off. For example, Safari shows that the web site is insecure with a big warning when they find out that the web server would allow TLS 1.0 or 1.1. Practically everything supports TLS 1.2 today, so it makes sense to make that the minimum version. The main exception is old VoIP phones. Some phones are so old that there is no firmware update available that would include TLS 1.2. My opinion is that they are not secure anyway and should not use TLS, and use TCP instead. This should work in many cases, except when there are firewalls that modify SIP/TCP packets. The bottom line is that for new installations I would definitively recommend to use TLS 1.2. For existing installations the motto is "never touch a running system" unless there is a need. When an old installation needs to use apps, that might be the need to upgrade to TLS 1.2 and move old devices to TCP. I would also recommend to turn the "ignore packets ..." setting on so that scanners cannot guess the DNS name for the server and do bigger damage. This should be working very well now in 68.0.14 where this is also happening on HTTP/TLS level when there are clients that don't indicate the server name.

That might be something on the client, not so much of the PBX? For example the VoIP phone would do that for you?

... as long as it resolves!

We'll soon release the 68.0.14, where you can see the release notes.

The problem is that 5406003047 is not +15406003047. It seems that when we were testing this, QuestBlue was sending this with the +-format, but in your case not. We'll add something that automatically converts it into the global notation (it would be easier if everyone just sends phone numbers in global notation). If you can it would be great if you can check if it is fixed in 68.0.13.beta so that we can include it in the 68.0.14 build.

Yes we should see 1.17 soon.

Well, the easiest would be to turn on logging to level 9 and see what happens when you receive a SMS. Maybe the numbers are not formatted in the right format or something. But because numbers are global (+1xxx) there should be no problem finding the right tenant.

There is the "camp on" feature where the PBX will call you back when an extension is busy. Would that be a solution?

What you could also do is to create tenants for each area code, especially if there are only a few area codes this will save you time for assigning dial plans

In the latest version you can make sure that all calls are sent to the trunk, even for "internal" calls. IMHO you should just give them their full phone numbers.

We had already made a change in the development version for this, so that the PBX will not respond to requests that do not match any valid name of the system. This can be controlled with the flag "Ignore packets that do not match a domain on the system" (/reg_security.htm). We will just include this in the next build (68.0.14).

There is a setting for each tenant in the domain settings that defines the default ANI for that tenant. That should solve that problem. For inbound routing, you need to assign the SMS DID to an extension or to a queue, so that the system knows where to send the request.

IMHO the ideal backup is a versioning file system where you can move back in time. Some cloud storage providers come with that. My second choice would be a cron job that tar the working directory at 3 AM when there is not much going on, skipping e.g. the recording directory because it just huge.

I would say the phone number that you are providing is not set up properly? At least we can say it is not related to anything like TLS or certificates. Does it work properly e.g. when you are using curl from command line?

I would turn on the log level for the web client, DNS and the TLS to 9 and see what is happening. Maybe you need to reset the certificate list or the DNS does not work properly.

You can use the "change setting" dropdown in the list of extensions to set multiple extensions (/dom_extensions_list.htm). The value would be something like the "0 8 ilbc".

Because the transmission happens over the wire, an internal FAX would not work this way. We could instead just put it into the recipient mailbox. Is that a use case that happens in a typical scenario? Or is this just for testing? Hmm, the PBX does not send FAX to the admin. Are the email addresses related and could cause a mix-up?

We will include that possibility in the next major release. In the 68 branch we will just change the ivr_ext field so that this will contain the extension number, if available. This should solve your problem. This will be in 68.0.14 once it is released.

So going through the tickets. Actually there was a ticket and it was not a master piece in seeing what the problem was (to put this mildly). What clearly has happened in your system is that the pbx.xml went out of sync with the data for the accounts. This causes the password to be garbled up and in your case it also wiped out the access list for the main admin account. I am sure that for example databases have the same problem if central configuration files are being overwritten. Here on the forum we will probably not find out what caused this and its probably too late anyway. In order to prevent this for others in the future there are a few steps that can be done: Before a software upgrade, make a backup. Hard drive space is cheap, and these discussions show how valuable backups are. If you are using file system replication, make sure that the pbx.xml file is in sync with everything else. Overwriting files from the PBX itself and from the replication software will cause chaos. After the initial installation, try rebooting the server and make sure that there is only one PBX instance running. Especially during initial installation it is easy to accidentally start a second PBX which is just sitting there and will grab the HTTP port as soon as the other one ends. A reboot will make sure that this has been cleared. Make sure that nobody has access to the file system unless needed.

We still would like to get to the bottom of this. It would be great if you could open a support ticket in the ticket system.

Yes that is a totally valid point. When testing this here, it did work however: You might have to write all records. Filtering by trunk does not work because that the CDR generation is leg based, and the leg that is associated with the might not have the extension. At least try to write all records. The other practical problem that we found is that the account number is written as index number. This Is not very helpful, and we'll change that to the extension number in the next build.