It has happened twice to me already that I wanted to make a phone call and found the number I wanted to use not working. In one case I contacted “support”, and in one case I made the call using a different number (sometimes it does not matter which number I call out from) and later received an email related to the failed call. In both cases it turned out that the cause of the probem was that VOIP.MS had blocked the number I wanted to use for the following reason: “Our system has detected and blocked a call attempt […] this is usually the result of making a call with a configuration that is different from the regular calling patterns of the SIP/IAX account, and is therefore considered risky or potentially unauthorized. Our system tracks and stops these call attempts in case of a compromised username or password.” Interestingly, the second time this happened, it was related to a number that has been registered “at home”, that is, via the same device, for a year already and with only one change of IP address during that time.
On the other hand, I move around a lot and end up using various computers and adapters in different parts of the world to log in to my accounts, and so I am afraid it will happen again that one of my numbers gets blocked, and that is most inconvenient when I urgently need to make a call from a specific number (banks, for example, use the number I call from as part of their verification procedure, so I only call them from the number I have registered with them). There is no error indication (message/announcement/special tone) that would tell me why the number does not work (I had previously mentioned this matter in another post).
I want to know what I can do proactively to avoid this kind of service interruption. Thanks in advance for related suggestions.
Just an idea, but maybe you could use a sort of VPN connection when connecting to your VoIP.ms server. Using something like this, you could get yourself a static IP, and no matter where your connection originated from, VoIP.ms should see the same IP address and validate the calls.
You may need to compromise on latency, if you’re travelling a lot, and connecting to the same VPN server at X location, the further away from that you are, the more latency will be on the SIP connection.
Sure, it’s a bit of a workaround, but it may provide more robustness in your ability to travel around and successfully make calls.
As for VPN, maybe look into Tailscale (they may be able to do this for free). This way, you could use your computer at home as the ‘VPN’, your IP could originate from your home. Then install Tailscale on your mobile, connect your softphone through Tailscale and voila, VoIP.ms will think you’re connecting from your house.
Unfortunately, in my case using a phone is not an option, since I use different (basic or “dumb”) phones in different countries and use voip services via computers, ATAs, or a desk phone.
But more importanty, I am sure that the IP address (changing or not) is not the deciding factor, since in some places the IP address is different every time one connects to the internet, and that has never triggered a block, while, as I had mentioned, I got calls blocked (involving two different numbers) when I called from a hardware device that is on a rarely changing IP address (that also happens to be the same IP address as the computer on which I have been using a softphone in recent months).
When they talk about “the regular calling patterns of the SIP/IAX account” I think they consider a combination of the user ID (subaccount) being used, the server (POP) being used, and (most importantly?) the hardware or softphone being used.
When I posted yesterday I had been thinking of how I could tell “the system” that certain devices I use are authorised (since apparently login ID and password are not considered enough). But now I think it would be simpler and more reliable if this kind of security check was set up as “opt out” service - I’d rather have it turned off because the probability of seeing any of my ID-password combinations compromised is way lower than that of getting blocked at times when it is most inconvenient. I guess I will write up a feature request…