Testing your VOIP phone during these difficult times

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 “Testing your VOIP phone during these difficult times”

Still more on the VOIP.MS denial-of-service attack

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.

Dealing with a VOIP denial-of-service attack

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 “Dealing with a VOIP denial-of-service attack”

A hard-to-get circuit breaker

The 50-ampere circuit breaker shown in the photograph at right is a very cleverly designed device called a “quad two-pole common-trip” circuit breaker.  It is actually four circuit breakers that have been squeezed into the physical space that would normally house two circuit breakers.  The two circuit breakers in the middle are mechanically linked by a cylindrical bar so that if one of them trips, they both turn off.  The outer two circuit breakers are linked by a stainless steel frame that, remarkably, accomplishes the same “common trip” function for the outer two breakers.  Why, today’s blog article asks, is this circuit breaker nearly impossible to find right now in September of 2021? Continue reading “A hard-to-get circuit breaker”

Thinking more about problem solving

A colleague of mine was wrestling with a homework problem that had been given to her schoolchild:

Jan has 35 teaspoons of chocolate cocoa mix and 45 teaspoons of french vanilla cocoa mix.   She wants to put the same amount of mix into each jar, and she only wants one flavor of mix in each jar.  She wants to fill as many jars as possible.  how many jars of french vanilla cocoa mix will Jan fill?

Continue reading “Thinking more about problem solving”

Thinking about problem solving

A recent column in the New York Times started with a math word problem, which I will oversimplify slightly here:

Sarah takes six hours to paint a fence, and John takes twelve hours to paint the same fence.  How long will it take them to paint the same fence if they work together?

One thing that is really fun about this problem, I think, is that it turns out this is exactly like asking “what resistance do you get if you put a six-ohm resistor and a twelve-ohm resistor in parallel?” Continue reading “Thinking about problem solving”

Charging electric ATV indoors triggers carbon monoxide detectors?

The other day I was baffled to hear a report from a friend who had recently purchased something called a Ranger EV. (A Ranger EV is an electrically powered ATV, shown at right.)  My friend described that she found she has no choice but to charge her Ranger EV outdoors, because if she charges it in her garage, it sets off her carbon monoxide detectors.  She is thinking about purchasing one of those new Ford F-150 Lightning EVs and was worried whether this means she would have to charge it outdoors too.

As I say, I was baffled by this.  Eventually I figured out what was probably going on.   Continue reading “Charging electric ATV indoors triggers carbon monoxide detectors?”

Fighting spam email — guilt by association

(Update:  our listserv server got migrated on about November 5, 2023 from an old IP address of 162.255.116.157 to a new IP address of 66.29.132.148.  As of November 10, 2023, the UCEProtect-Network lists both of our dedicated IP addresses 63.250.38.181 and 66.29.132.148 in its UCEPROTECTL3 category.)

Yesterday our firm came face-to-face with one of the ways that email system administrators fight spam — a very interesting guilt-by-association system called UCEProtect-Network.  This system collects spam reports and carries out a “cluster analysis” (Wikipedia article), aggregating the reports by groups of IP addresses from which the spam emails originated.  The practical result is that everybody who uses Microsoft to host their inbound email has stopped receiving any email from our firm (“oppedahl.com”) or from our listservs (“oppedahl-lists.com”).  This is not because either of our IP addresses has ever been the source of spam (neither IP address has ever been a source of spam) but because other IP addresses that are “nearby” to our IP addresses have been the source of spam.  Continue reading “Fighting spam email — guilt by association”