Vodia PBX

Of course we take this serious. However we need to understand what has happened here. If you whitelisted IP access it should be unlikely that someone outside hacked your system. You can check the access log for log entries if you would see any suspicious login activity. From what I can see the most likely scenario is that your pbx.xml was corrupted and reset to factory after a restart. This would clear the admin account name, the admin password and also the the IP Access settings, and many other things. When the system starts up it needs to figure out if this is a fresh install, and it looks like it came to the conclusion that your system needed that. We have seen cases where the pbx.xml got out of sync, e.g. because of an rsync process overwriting it with similar outcomes. What we have also seen especially on MacOS is that the PBX process starts with without permission to access the file system, and it tries to read the pbx.xml which fails, which will have the PBX initialize it again, and when finally write permissions are granted, it will overwrite the pbx.xml with that new pbx.xml file. This could be a problem e.g. if your firewall blocks the PBX executable after a software update and restart, and a later "Ok" on the firewall admin page. Without being a big Windows expert, I believe that scenario could be happening with the Windows Firewall. If that is all true, what is the take away? Takeaway #1 is to make a backup before the upgrade, so that if something should go wrong there is a point where you can go back to without headaches. Takeaway #2 is that after a software upgrade you need to tell the firewall somehow that the PBX executable is okay, or at least not ok file system access after the PBX is already running. Takeaway#3 is for us, we'll add a check if the PBX can read a file successfully, and only if that is the case create a new pbx.xml, otherwise exit and not continue the boot up process.

I think the problem is that you are using the file: scheme. That scheme has hard coded fields. Could you try the cdr: scheme instead? Then you can control what is being written. In 68.0.13.beta (currently available for CentOS64 and Debian64) we have added the $(ivr_ext) field that should explicitly contain the extension.

That might be a good reason to add park orbits to the mobile apps! Star codes still work, but are indeed clunky.

Are you able to download the configuration XML? Does it look like the regular Polycom XML? Then it could be relatively simple to just add that model.

An empty admin password on public IP yes is an invitation for chaos. The problem is that for installation we need to start with a well-known default setup, and it does not matter what it exactly is but after the first login the admin should really be forced to change the password. I doubt that the password just spontaneously changed. There must have something else happened to cause a password change. Did anybody have write access to the file system? This would be a major problem because yes that can screw up the installation. Please make a copy of the pbx.xml; an empty password for the admin would mean that the pw_pass entry must be empty. The other thing that helps is to limit admin access by IP address. We recommend this also for SSH access and it does keep trouble away. And yes its a good idea to have backups from time to time. If you have a backup, you can go back no matter what happened.

Yea I am not 100 % sure what exactly happens, but it does not redirect it to another location (that is 100 % sure).

Well a few public park orbits would probably be fine and everyone can use them e.g. for that purpose. Sharing held calls with all registered devices would be a proper solution but does not work with standard SIP devices. We shall see how common this request is and if it deserves coding something.

Hmm maybe can you attach an example? Maybe the local field is formatted in a different way, requiring parsing of that field?

Hmm does that even work with SIP? As far as I remember that was the phone for Teams which talks "TEAMS", a protocol loosely inspired by the SIP protocol .

Maybe https://doc.vodia.com/v1/docs/integrations-framework will be useful to address this integration.

Its an older post, but that does not mean its forgotten! Version 69 will add some new possibilities for integrating CRM systems. There is already documentation available, if you want to check out https://doc.vodia.com/v1/docs/integrations-framework.

Right now the PBX would just reject the request.

Hmm my only idea would be to park and then retrieve the call.

Looks like this OID log message was not supposed to be in the release build. And definitively not on level 0. Next version will not log it any more.

You mean you don't want someone to get to the PBX by using an IP address? There is a setting called "Ignore packets that do not match a domain on the system" (/reg_security.htm) that might do what you are looking for.

Are we talking about the file in https://doc.vodia.com/docs/cdr, something like $(account)?

Is the for a SNMP walk? Or maybe just attach the log here...

This is because there are still references to the CDR however they were obviously already deleted. At this point this would be more of an inconvenience.

I just tried on our own server. It took me an hour to figure out that the server certificate had expired and there was a domain certificate with the same name that was refreshed instead. Also I am not sure if my phone had problems because the DHCP server would set the NTP server and because of that would not have the current time for validating the certificate. After that it worked well (firmware version 5.9.7.3480 on a VVX300). PBX Version 68.0.12.

You could also just redirect the call into a IVR node where everything is already available.

Not. monitor, but a way to change the state of a service flag. It in the menu on the top right where you would also find settings. In 68 this will be limited to manual service flags, but in 69 it will also cover automatic service flags.

On that one there is no variable available. But it does make a lot of sense. We'll include {from}, {to}, {cmc} and {lang} in the next build (68.0.13.beta).

We did make some progress, e.g. there are roles for managing the shared address book, queues and access recordings. IMHO things like changing trunk destinations should be done by a domain administrator and there should be no such role for end users. But for example more management of ring groups could be something than an end user could do.

I mean where did you put that URL in the PBX? In the SMS GET?!

So what are you using? An ActionURL? What are you getting right now in HTTP?