click to enlarge

I have written about how the swallowing of the service provider Afex by Cambridge Global Payments (aka Fleetcor, aka Corpay) has been a disaster (blog article, blog article, blog article).  One of the most recent developments is that, perhaps in retaliation for these blog articles, a manager at Afex unilaterally decided to close our Afex account.  This of course required figuring out how much money was in our account at Afex and then transferring it to one of our accounts at some bank account.   It now looks like the manager did his math wrong, transferring an incorrect amount of money.  And the so-called EZTrack web links that are supposed to tell us the status of the money transfer to us do not work.  You can’t make this stuff up if you try.  Continue reading →

click to enlarge

However bad I thought the swallowing of Afex into Corpay (Fleetcor, Cambridge FX) was (see blog article and blog article), I was mistaken.  It is worse.  I cannot in good conscience suggest that any Afex customer spend even a moment trying to preserve their customer relationship with Afex.  Here are the latest disasters.  Continue reading →

It will be recalled (Afex Going Down the Tubes, September 30) that it seemed to me that money transfer service provider Afex, recently purchased by a company I never heard of before called Corpay, was going down the tubes as part of its process of being absorbed by Corpay. 

If anything, my reaction is that things are worse than I thought.

It will be recalled that the various documents and FAQs that are meant to reassure Afex customers that the acquisition process will be seamless say over and over again that your Relationship Manager will always be there to help.  The small problem being that our Relationship Manager had left the company a few months ago and no new person had been named as her successor as our Relationship Manager.  And it will be recalled that one of the FAQs helpfully provided a web-based form that a customer could complete and then a Relationship Manager would call the customer back Real Soon Now.  So I filled out the form and clicked submit and an email showed up a moment later thanking me for submitting the form and letting me know that my Relationship Manager would be getting back to me Real Soon Now.  That was on September 30, which is eight days ago.  And as of today, you guessed it, I have not heard back from anybody.

So yesterday I tried logging in on the Afex system for sending money transfers.  I did a test transfer to our firm’s own bank account.  That was yesterday.  The money should have reached our firm’s bank account by today or so at the latest.  Then every few hours I would click around in the Afex system trying to see some sort of confirmation that I had done the transfer.  Nope, no confirmation.  Finally today, about 26 hours after I did the transfer, a confirmation showed up.  The confirmation is worded and dated as if I had clicked “submit” today and as if the money probably won’t show up in our firm’s bank account until way next week some time.  Not good.  But so anyway I did happen do see that in the confirmation, it names an actual human being and provides two telephone numbers to call.  

click to enlarge

I dialed the first number which is 303-471-1161.  I get a recorded message “your call cannot be completed as dialed”.  I dialed the second number which is 866-428-2151.  The call goes through and is answered.  But it is answered by the squeal of a fax machine.  Or at least I am guessing it is a fax machine.  It is definitely not a human being.

Not good.

I cringe to imagine how stressful things must have been in recent weeks at VOIP.MS, the provider of unbundled VOIP telephone services that we like to use.  As I reported in earlier blog posts, they were apparently attacked by a DDOS (distributed denial of service) attacker that demanded a ransom as a condition of stopping the attack.  My impression is the attacker never penetrated any of the systems of VOIP.MS, but merely flooded its servers with spurious data packets that were intended to overwhelm the servers so that normal customer activity was not able to take place.  

Anyway, the result of all of this is that the people at VOIP.MS had to take a variety of measures to harden their servers against the attack.  This required them to devise sophisticated ways to turn away the spurious packets while still, hopefully, allowing legitimate data packets from ordinary customers to work their way to the servers.  

So by now in our firm, we have migrated all of our phones and ATAs and other devices over to the various newly hardened servers.  And we have been doing daily tests of the various functions, including test calls to the ever-popular test phone number 720-230-1331 (try calling it!).  And so far as we can see, things are stable now.

Loyal readers from a long time ago will recall that although I am now pretty enthusiastic about using Transferwise (now renamed “Wise”) for money transfers, before I discovered them my service provider of choice was Afex.  Afex was my service provider of choice because it was less bad than Travelex/Rausch which in turn was less bad than Western Union.  

But even though Transferwise turned out to be better than Afex in almost every way, I found I had to maintain our account at Afex for two reasons:

• there are a few places where we were unable to send money with Transferwise (for example to businesses in Brazil) and Afex was able to do it;  and
• there are a few countries where the sender might be located and they cannot send USD (US dollars) to us at our Transferwise bank details, but they can send USD to us at our Afex bank details.  One example is Lithuania and another example is the Cayman Islands.

But now it looks like Afex is going down the tubes, as I will detail.  Continue reading →

In an earlier blog post I mentioned that if a customer thinks they can dump VOIP.MS for another provider (because VOIP.MS is on the receiving end of a denial-of-service attack) and thus be clear of service troubles, the customer is probably mistaken.  My reason for saying this is that whoever you switch to, they could well be next in line to be attacked.

And that seems to be just what is happening. Continue reading →

If your phone service relies on the provider VOIP.MS, then like us at OPLF you are from time to time needing to place a test telephone call to try to figure out whether the latest thing that you changed in your configuration has left you with functioning telephone service or not.  This is part of dealing with the denial-of-service attack that is going on even now  (blog article) against the provider VOIP.MS.

And even if your phone service does not rely on the provider VOIP.MS, it is probably only a matter of time before some denial-of-service attacker will attack the provider that your phone service depends on (this is happening, see blog article).  And when that time comes you are going to need to place a test telephone number from time to time to check to see whether your VOIP service is working the way it is supposed to work, or whether the most recent thing that you changed made things better or worse.

Wouldn’t it be nice if somebody somewhere would provide a telephone number that you could call at any hour of the day or night, and you could speak and hear your own voice repeated back to you (or not), and it would tell you that your VOIP service is working correctly (or is not working correctly).  I am pleased to remind you that there is such a telephone number.  Continue reading →

click to enlarge

Well this is a bit annoying.  I had been closely following the various email blasts from VOIP.MS that are intended to let customers like me know how to react to the denial-of-service attack (see recent blog posts).  I had gone to quite a bit of trouble to reconfigure several phones and ATAs at several physical locations to make use of the chicago3 server instead of our usual denver2 server.

Then sort of on a whim I happened to click around on the Twitter feed of VOIP.MS.  There, sort of as an aside, the people at VOIP.MS happened to let slip that each of their servers that has gotten “hardened” against the DDOS attack, and that now has a green check mark, is no longer supporting encryption.  Each of the green-check-box servers is usable only on port 5060, not port 5061, and you can’t use RTSP.

This means that all of the hard work that I did to reconfigure several phones and ATAs at several physical locations to make use of the chicago3 server instead of our usual denver2 server was a waste of time.  Those phones and ATAs still will not work because they are all set up to use TLS and RTSP for full encryption of the telephone calls.

Now I get to start all over again, clicking through VPNs and otherwise doing whatever is needed to log in to each of the various phones and ATAs to do about four times as much reconfiguration as I had previously understood to be necessary.

Previously I thought that all I had to do was find the screen or popup window where “denver2.voip.ms” appears and change it to the IP address of the chicago3 server.  But now for the first time, only sort of by accident by clicking around in a twitter feed, I have learned that I must also:

• click around to find the screen or popup window to change “5061” to “5060” for the SIP port.
• click around to find the screen or popup window to change “TLS” to “UDP” for the SIP protocol.
• click around to find the screen or popup window to change “SRTP” to “RTP” for the audio transport protocol.

In all of my devices these settings are in three different places — a first place for the server, a second place for the SIP settings, and a third place for the audio protocol settings.

And it is not only me.  Each of my staff people is going to have to go through this much more complicated reconfiguration process.  Once right now to get to a “green check box” server, and again at some future time when it once again becomes possible to turn the encryption back on and to migrate back to a Denver server.

Oh and not only that.  It is going to be necessary right now to turn off encryption for each of our SIP trunks (what VOIP.MS) calls “subaccounts”.  And at some future time it will be necessary to turn the encryption back on for the SIP trunks.

click to enlarge

Here is how things are looking on the denial-of-service attack (previous blog article) on VOIP.MS, my favorite VOIP service provider.  Continue reading →

Some years ago our law firm migrated away from every old-fashioned landline telephone provider that we used to use, and we moved everything about our telephone service to a Canadian VOIP telephone company called VOIP.MS.  I have blogged frequently about my satisfaction generally with the use of VOIP rather than older ways of getting telephone service, and I have blogged frequently about my satisfaction in particular with this company as a provider of such services.

Which then leads to a sense of wonder and frustration to see that somebody has chosen to bring a denial-of-service attack against the VOIP.MS company, and has asked that a bitcoin ransom be paid for the DDOS attack to cease.  (See Ars Technica article.)  This has led to various disruptions in service for many of the 80,000 or so customers of VOIP.MS, some of which (as for my firm) have been intermittent and some of which (for some customers) have been pretty much continuous.

What can a customer do about this, if anything?  Continue reading →