rtl
-
Posts
52 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by rtl
-
-
15 hours ago, Vodia PBX said:
What would you expect for the UK
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.
On 5/12/2022 at 9:53 PM, Vodia PBX said:. Extension or seat-based-models are much easier to understand and practically the whole SaaS world follows that model today,
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.
On 5/12/2022 at 9:53 PM, Vodia PBX said:if you are too high customers feel ripped off about paying for a license that is not needed 99.9 % of the time
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
-
21 hours ago, Vodia PBX said:
There are only very few cases where a holiday starts in the middle of the day, I am not aware about holidays in the UK that would fall into that category?
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
-
13 hours ago, Vodia PBX said:
This causes the password to be garbled up
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.
-
8 hours ago, RichardDCG said:
Isn't the issue they got access to your MT server?
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.
45 minutes ago, Vodia PBX said:I doubt that the password just spontaneously changed.
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.
-
Quote
68.03 RC (Release Candidate) - then notes on what is being worked on.
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.
Quotemove to 68.0.5 for more daily builds.
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
Quote<!-- Reregister Before Expiration (in seconds). Default is 0 second -->
<P2330>0</P2330>The vodia template however has
Quote<!-- Reregister Before Expiration (in seconds). Default is 0 second -->
<P2330>15</P2330>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.
Quoteand why Grandstream would even change the behavior of this setting.
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
QuoteWe've had no customers complain about this, so rest assured this should be working
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.
QuoteI would be surprised if the firmware would have such a fundamental change
So would I but the evidence is incontrovertible
QuoteWe've had no customers complain about this, so rest assured this should be working
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
Manipulate extension ani
in Extension Setup
Posted
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