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. One of the unbundled VOIP providers that might be thought to be a choice for who you might switch to from VOIP.MS is Bandwidth.com. They are really big (much bigger than VOIP.MS) and I find their systems much harder to use. But for some high-volume users who can somehow figure out how to use their systems, it is possible to save quite a bit of money using Bandwidth.com as compared with VOIP.MS.
And as you can read here, a denial-of-service attacker has just now apparently selected Bandwidth.com as a target. This affects ordinary end users of the company (such as one client of our firm) and it affects quite a few downstream companies that provide a variety of retail VOIP services, bundled and unbundled, including Twilio, Accent, Dialpad, Phone.com, and RingCentral.
There are several things that can be said about this. A first is that this reinforces my sense that it would be unwise to go to the trouble of migrating away from any particular provider of unbundled VOIP services with the idea that this would somehow mean that you would then no longer need to worry about problems like this. A second is that in a weird way I think it may turn out to be really smart to migrate to VOIP.MS, once they get suitable defenses all worked out, because they will have been among the earliest of the unbundled VOIP service providers to do so. (“What does not kill me makes me stronger”, that kind of thing.)
I left critical inbound numbers with the expensive telco but just for local service. Then I forward to a provider hosted number which is local to that inbound number. Thus I can change providers in seconds. At the onset of this issue I did not have a second provider I could easily switch to, but now I do.
My experience in the past has been that when Verizon forwards a local telephone number to a VOIP provider, Verizon permits only one call at a time to be forwarded to the VOIP provider. Thus, when I was on one call that had been forwarded and a second call tried to reach the Verizon provided telephone number, that second caller experienced whatever behavior Verizon provided for calls to a busy number (e.g., a busy signal or a transfer to Verizon’s voicemail system, depending on configuration of the Verizon switch).
Your millage will vary, but one inbound call at a time was a deal-breaker for me.
So too was a need to check for messages on both the Verizon system and the new VOIP system.
This baffles me. There are some DIDs in some countries that have a limit on the number of “presences” meaning the number of simultaneous incoming telephone calls that can come in from the PSTN. For example if you get a DID in China it almost always has a limit of two simultaneous incoming calls.
And there are some providers of unbundled VOIP service in the US who provide DIDs for which there is a limit on the number of “presences”. But VOIP.MS is not among them. The DIDs that VOIP.MS provides have no built-in limit on the number of simultaneous incoming calls from the PSTN.
Having said this, what is very important to keep in mind is that the way SIP works, absolutely each and every setup and tear-down of a SIP telephone call requires an end-to-end set of handshakes all the way from the originator of the call to the would-be endpoint of the call. If you are dialing from a Verizon cell phone then it is clear to all of us exactly who is the originator of the call. It is your cell phone. But who or what is the “would-be endpoint of the call?” Sometimes this requires a bit of thought. For example suppose the would-be endpoint is a physical SIP phone. In that case, the question is, is that physical SIP phone configured to do “call waiting”? That is, can it gracefully handle a second incoming call while it is already handling a first incoming call? If yes, then that is one thing. If no, then that is another.
The point here is that if you are dialing from your Verizon cell phone to a DID, what gets initiated is an end-to-end series of SIP handshakes, that might or might not reach a happy conclusion at the would-be endpoint. Maybe the would-be endpoint is a physical SIP phone that says the SIP equivalent of “I am already handling a phone call, please go away” in which case the result of the attempted handshakes might be a busy signal returned to the Verizon cell phone, or might be the call being sent to a voice mailbox somewhere within the VOIP system of the VOIP customer who owns the DID number. Or maybe the call goes to a hunt sequence and eventually to an IVR for more complicated handling. And by the way what I find astonishing is that the first attempted end-to-end series of SIP handshakes probably reaches closure (or lack of closure) in 750 milliseconds, and then the alternative path that runs to the voice mail box (or to the hunt sequence, or to the voicemail box) might only add on another 150 milliseconds before some human-understandable feedback is provided to the Verizon cell phone user.
When you receive the “thank you for using Verizon. your call cannot be completed as dialed” this almost certainly means that the very first attempted end-to-end series of SIP handshakes somehow did not finish and the way it failed to finish was in a way that looked like there was never going to be any alternative path either. The explanation however is almost certainly not “Verizon puts a cap of one on the number of permitted calls to that DID”. Verizon is not in a position to maintain any real-time count (across its entire service user base?) of the number of attempted calls to any single DID. No, the explanation is some failure of the attempted end-to-end series of SIP handshakes. This might be as simple as, the physical SIP phone was unplugged from its ethernet cable and the cloud PBX to which it was configured had no alternative path defined for that DID. Or (for this DDOS attack) the physical SIP phone had been unable to look up the IP address for the FQDN for the server that it was trying to register to, thus no SIP trunk registration had been accomplished, and again maybe the cloud PBX had no alternative path defined for that DID.
I think what Newton was getting at was that when a call comes in to whatever equipment at Verizon (or any telephone company) handles a call for a first directory number and forwards it to a second (forwarding-target) directory number, Verizon may limit the number of simultaneous calls Verizon will forward from the first number, regardless of the readiness of the equipment accepting calls for the second (forwarding-target) number to take additional calls.
The traditional rationale for this was that each forwarded call used a variety of resources–trunks, switch fabric, call-processing capacity, inter-carrier interfaces, etc.–from limited pools, which are sized (“engineered”) based on prior patterns of use. Imagine the situation where some business that typically receives many incoming calls that persist simultaneously orders a single local telephone line from TELCO with a widely advertised directory number and forwards it to another number served by some other carrier (which could be traditional or unbundled). Absent the limit, maybe TELCO would be carrying 100 or 1000 simultaneous forwarded calls, but is being paid for a single line.
TELCO might have usage-sensitive rates for the forwarded call that are intended fully to compensate TELCO for the marginal resources used for each of the simultaneous calls. However, in my experience with such forwarding (n=1), the usage-sensitive rate for forwarding was the same as the rate for originating a call from that line–i.e., the forwarding rate might be seen as capturing the marginal cost of the outbound leg of the forwarded call. But there was no apparent charge to recover the marginal cost of the incoming leg of the forwarded call, of which one instance at a time might be seen as included in the service of a regular local telephone line, but not 100 or 1000. Thus, the marginal cost of the incoming leg of many persistent forwarded calls may not be recovered in the rate. Even if it is, the usage-sensitive cost recovery doesn’t compensate TELCO for the simultaneous unplanned tying up of limited capacity and resources in the network, which may affect TELCO’s ability to serve other customers, or, if the traffic persists, may require TELCO to allocate capacity to handle it.
The traditional rationale may no longer be appropriate for some classes of calls in the VOIP era.