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.

What we need is a release strategy. Release beta code that should *not* be deployed as production. Use the user base to feed back issues then incorporate the fixes, if any, into a new release that's also beta. Once there's a stable release that's been tested then release it. This approach bothers me. Why have daily builds and release them? It much more sensible to produce daily builds for testing then when there's a beta candidate release it as such. Eventually you have a release candidate with is then release for general use. The vital point here is not to release daily builds with the same version number. If you have a 68 branch that,s OK but when and how do you merge those changes back into the main trunk code... and what's the strategy for doing so to ensure stable releases are in fact stable so we avoid what happened with the initial release of v68

Agree, we need detailed release notes before even considering moving from v67 given the debacle of the release of v68

Where handsets are concerned GDMS supports the GRP261x, GRP260x, GXP21xx and WP810/820. As I understand it the GXP16xx and GXP17xx will not be supported (processor too underpowered). There's no need to use GAPS as handsets will look for a config in GDMS and provision from there. If you have a GAPS profile it will use that however if there's a GDMS profile as well it will then use that. I used GDMS to deploy over 150 GRP2602/GRP2615 handsets earlier this year on Vodia and it worked flawlessly. I rarely use GAPS now apart from for unsupported handsets (on GDMS that is)...GDMS is much more capable. As for integration with GDMS there is an API that can be used. for integration https://doc.grandstream.dev/GDMS-API/EN/#api-157121573453101000009

What else has changed in 67.0.5? I can't see the release documented in the release notes

I've resolved this. Every system I've provisoned the handset from sets this value thus The vodia template however has Change the value from 15 to 0 in the template and it should work. I can't see how this has slipped through testing at Vodia...but it seems to have done. Grandstream didn't change the behaviour of the setting rather Vodia changed the value in the template from 0 to 15

I've found that if I configure a handset manually, not using a template, then the registration holds. If I attempt to provision from a template then the registration is unstable. Must be something in the GXP21XX template that produces a dud config file

No it wasn't changed...I've been working with grandstream developers on trying to resolve this for some weeks now and they can't get to the bottom of it. "Reregister Before Expiration (in seconds)" is set to 0 as default on the fw in question and those before it. The issue relates to the GXP21XX series with fw 1.0.11.35 and 1.0.11.39 and only with Vodia. The exact same config on the handset works as expected with 3CX, Grandstream UCM, Freepbx, asterisk but never on Vodia

There's a feature in 1.0.11.35 we need for remote handset management. I've tried everything I can think of to resolve this including ending traces and syslog to Grandstream and talking to their firmware engineers. I'm going to have to move my customers to another system . It's disappointing to hear comments such as from Vodia support. Shows little or no appreciation for their customers

It only happens on 1.0.11.35. Works fine on 1.0.11.16, 1.0.11.6 and previous. This happens on 67.0.1, 67, 67.0.2, 67.0.3 and 67.0.4. Handsets were provisioned from the Vodia server as usual. So would I but the evidence is incontrovertible Yes it should be working...but the reality is it isn't

I found this on all the GXP21XX handsets. They work on other systems (3CX, Asterisk, Grandstream UCM) but not Vodia. I flagged it up to Grandstream and had several long conversations with them and we weren't able to resolve it. It seems to be a real issue and if Vodia can't resolve it we'll have to move away from Vodia. I was under the impression Vodia supported Grandstream, the implication being they test against Grandstream beta firmware but this can't be the case