I’m checking to see if anyone else is experiencing problems with the VoIP.ms softphone since they performed the recent “upgrades” on the various server.
Before the upgrade, everything worked normally. Immediately after the upgrade, I’ve been unable to place any outbound calls from the softphone unless I first receive an email asking me to approve the call. This never happened before, and it’s turning into a real waste of time.
I’m trying to determine whether this is just happening on my account or if others are seeing the same issue.
If you’re using the VoIP.ms softphone, are you having similar problems?
You are right. I am also unable to make any calls at this moment with Groundwire (almost the same app as VoIP.ms softphone). I am also getting an email.
Since the IP restriction and POP restriction are both desabled on my main account and sub accounts, I think this is a new problem. (Recent update?)
So, after opening a ticket, the tech support team was able to fix the issue (on their side) prety quickly.
Now my outgoing calls work as usual without incorrectly detecting them as potentially unauthorized and receiving a “Potentially Unauthorized Call Blocked” email to authorize a configuration change.
If you still have an issue, open a ticket. They will fix it quickly for you too.
I got nothing more than the standard voip.ms B.S., see below…
Thank you for your message.
This behavior is part of a security measure introduced to help protect customer accounts from unauthorized outbound calls. When a call is initiated, the system may send a verification email requiring authorization before the call can proceed.
We understand this may add an extra step to your calling process, and we appreciate your patience. Simply confirming the call through the email will allow it to complete successfully
I just spent the last 3 hours trying to troubleshoot the same issue. Reset passwords. Deleting and reinstalling the softphone app. Following all steps in the YouTube outbound call troubleshooting video as well as the steps sent by the support bot. I also received the “Potentially Unauthorized Call Blocked” email and authorized the configuration change, but still unable to make outbound calls.
Just opened a support ticket, so we’ll see if that helps.
Strange, I had a good and responsive experience. Maybe it is the way the ticket was formulated? Here is a reformulated version of the ticket I sent:
Topic: Termination Issue Subject: Unable to make outgoing calls (IP block)
Hello,
I tried to make a phone call with Groundwire (Android) and it did not work:
I got an email “Potentially Unauthorized Call Blocked” with my phone’s current IP address.
This is a new behaviour and I do not want to have to authorize every single IP address my smartphone will have.
I do not know what changed, nor what to do to make it work as it was before, as:
The POP restriction is NOT enabled on my account nor sub account.
The IP address restriction is NOT enabled on my account nor sub account.
I changed nothing in my settings anywhere. It just started to “not work” and send emails.
I am using GroundWire on Android.
My sub account is: subaccount_name.
Is it possible that a recent change on your side broke something? I would like all calls to work as before, and also when I travel and pick a different POP server. I do not care about the IP and POP restrictions.
Well apparently support thinks it’s totally reasonable for us to sit here and wait 2–3 minutes per call just to validate it. Because who doesn’t have that kind of time to burn every time they need to dial a number, right?
Hi. About a week ago, I started getting the same problem. I am using a softphone “app” on an Android smartphone (Groundwire if it matters). After a call is blocked and I get an error, a few minutes later I get an email that describes a possible security problem because of a changed configuration. In the email there’s a button to "authorize” the configuration change, and that fixes it, and I can make calls again. Temporarily only, until the next IP address change.
So what is the configuration change? Yes, as unbelievable as it sounds, it is that the IP address changes. Apparently VOIP.ms thinks that when a cell phone (portable pocket device!!!) changes its IP address, this is a possible security issue.
I went through the ticket process. According to Tech Support, this is not a bug, it’s by design. Here’s the response:
“Yes , the “Authorize Configuration” step will need to be completed each time your IP address changes and triggers the security protection on the account. This is expected behavior of the
current anti-fraud system designed to protect SIP accounts from unauthorized usage.
If you are frequently moving between networks (Wi-Fi or mobile data), this security check may appear more often. Once you receive the alert email, you will need to click “Authorize Configuration” and allow a short time (15–20 minutes) for the system to update and re-allow calls.”
Yes, VOIP.ms expects you to take 15-20 minutes each time a mobile/portable device changes its IP address. Wow.
I opened a new support ticket and copied/pasted your ticket and just changed the details on the softphone and subaccount to mine. I am curious what their response will be this time.
My ISP was recently bought out and switched to a new company. I lost my external static IP and now get to experience lovely CGNAT :(. My external IP address now switches often, so the explanation above makes sense. I’m glad I ran into this now with my test DID because I just bought a wifi IP phone and was going to port my landline number over. I’ll try to get an authoritative answer from support if the IP address switching issue is the cause, and if there are any plans to fix this. If it’s by design, then voip.ms isn’t an option for me. I hope that’s not the case.
And this morning, I couldn’t log into the portal, I wasn’t allowed to reset my password, and now I get a message that I’m being rate limited when going to the portal and now completely blocked. Something’s going on with their IP address tracking.
We may be getting some progress on this issue. This evening (April 15), I did this: Call while on cell carrier’s network. Went through ok. Activate “airplane mode” and connect to local wifi (forces an ip address change). Call went through ok. Turn off wifi, turn off airplane mode, and go back to cell carrier’s network. Call went through ok.
I’m honestly not convinced anything we’re doing is actually fixing the problem. What it does look like is that they’re finally realizing we’re getting pee-d off. Your tests tonight are good, but I’m not ready to call it progress on their end. More like they’re scrambling because they know we’re fed up. Let’s see if this holds and isn’t just a one‑time fluke.
Here is a reformulated version of the ticket I sent: