rtl

I'm trying to set outbound ani based on the number dialled. According to the documentation if I put 01482:02034444444 01384555555 or 441482:02034444444 01384555555 or +44482:02034444444 01384555555 in the "Outbound Number (ANI)" field and dial a number beginning 01482 I should show 02034444444 as CLI and any other number dialled should show 01384555555. But it ALWAYS shows 01384555555

I'd expect 0044 which is there however as the UK is no longer in the EU I needed to clarify

The dial plan documentation lists country area codes like this. Are there any plans to add the UK?

I find sim call licences much easier to sell than per seat. It's straightforward to estimate the number of calls in a sim call environment...we've been doing it with 3CX for 13 years now. The per seat is much more tricky. Customers gain and lose staff so we continually have to adjust the licence which is a pain. Sim calls simply mean we sell the licence, extensions can be added as and when and we adjust the sim calls as and when necessary. Customers prefer it and ask for it which is why we're staying with 3CX and moving vodia installations to 3CX where we can. Just because everyone else does it isn't a valid business case for doing it. You should be leading not following and listening to what resellers want. We want it because we can sell it and it's what our customers want. I have several customers who have a sim call licence that's too high. They don't know that neither do they care. What they care about is do they get a service with which they're satisfied and content and they are. They're too busy with their own businesses to look at the number of sim calls they're using.

Which is what I did and followed the documentation which appears to be wrong which is the whole point of the question. It's clearly documented but doesn't work

There are no statuatory holidays that fall into that category. However many businesses take time out for training, the day before a statuatory holiday where they may end at midday and so on. It's actually quite common hence why I used it when I saw it documented.

That doesn't explain why the date/time format doesn't work as documented as I've highlighted

Been trying to configure a service flag from this on https://doc.vodia.com/docs/serviceflags but it won't follow the time. If I use dates only then that works. It also doesn't seem to accept dates on the format DD/MM/YYYY as documented. Using v67.0.5

I back up each tenant every day using a cron task and I also zip and copy the pbx directory and then zip them all together and send it to S3 storage at digital ocean

It removed the password rather than garbling it. I've added an .htaccess password to the server. We're moving to another pbx right now. Our insurance company and lawyers will handle the fallout from this

I've opened several over the last two years and got nowhere apart from trying incognito more and scanning for malware. I'm moving to another pbx so if I have time I will do so

MT=Multitenant I'm using debian 10 vodia 67.0.5. Tried v68 just after it was released and it was a bag of nails so we're not going anywhere near it. All I know is what I've described and all the information I have. I've flagged it with Vodia support several times and they're no help. I've installed a number of monitoring tools and scripts and can see nothing to point to how this happens. Everything points to an issue with Vodia but without engagement from the company I can't make progress. In any event we're in the process of moving everyone on the MT server to another pbx. There's a couple of big CPE licences that will follow in time.

You just don't understand the post do you. The passwords, admin IP access settings, SIP trunk passwords and user's SIP passwords were set to empty. Thus the server was open to anyone. The issue is why were the passwords deleted? This isn't the first time its happened. Although yes the issue is indeed they got access to the server but this was due to the Vodia software wiping them. So that is the real issue. I understand there's an issue whereby when there is a corruption in the CDR exactly this happens...I got this information from Vodia. Vodia have apparently been aware of this for some time but haven't dealt with it. My advice to anyone using or considering Vodia is just don't.

Right, you don't understand. I'll set the position out clearly and hopefully you will see there's a real issue with security here. 1. This server has been in operation for 2 years or so. 2. The password we used was secure...32 characters, upper/lowercase/numbers 3. The password has disappeared spontaneously several times. I've raised it with support and the response has been to look for malware on my PC and use incognito mode...as if either of those would make any difference 4. We have access to admin login secured to a few ip addresses. This disappeared too. 5. SIP trunk passwords were changed 6. Users web client passwords were corrupted. 7. We have a backup taken every day 8. SSH access is limited to a single ip address and authenticated by public key. Password login isn't permitted This isn't the first time it's happened and the only explanation is an issue with your software. This is NOT a new installation. As I have said twice, I seen this several times and raised it with support. The response has been disappointing. As you have not addressed the point at all we have no option other than to find an alternative to Vodia that works as described.

Last night someone got access to the Vodia management interface on my MT server and caused chaos. It turned out that the server had wiped the admin password leaving it blank, changed or wiped all the trunk passwords and removed the password restrictions for system admin login. I've seen this before on v66 and v67 (using 67 now) and always managed to catch it before anything like this happened. I've raised it with support and haven't got anywhere. It's a real security issue and there seems no explanation so I'm looking for another pbx. Its a shame really as I like Vodia but I can't use it with this enormous security hole.