I’m having issues today with multiple accounts being unable to terminate calls through the Chicago POPs. On my test FPBX box - I can dial out through atlantaq but chicago2 return 486-Busy Here. Opened a ticket with VoIP.ms but not holding my breath for a quick response.
Thanks Ray.
Maybe there is some industry insider Mojo that is required - my porting guy at Flowroute told me a TFN ports like any other number and usually takes at least 24 hours and usually longer.
The reason I am so interested in this is because this seems like a good answer to customers who ask “how do we prevent this from happening again”. If I knew that TFN portability had real advantages, then I would have a good response to that question.
I had mentioned in a comment to your original video with Tom that I honestly feel that maintaining call-forwarding functionality under nearly any circumstances should be part of the contingency planning for a VoIP provider. Receiving and forwarding a call on a server that is on a private IP space should be possible - unless I am not understanding some part of the equation. Of course, that assumes your tier 1 provider is always up - which I guess is now off the table anyway.
This blog post from Cloudflare explains it all
1 Like
Depending on the size of your business you could split your voice service on 2 PBX systems or have a few POTS line for backup and there is always cell phone as last resort. Some form of voice is better than zip.
Another round of outages - VoIP.ms is saying it is “one of our upstream US providers” on Twitter but Bandwidth status page is not reporting the outage. 
As of yet no id of those launching the attacks. Round up the usual suspects.
I wonder if SIPS and client auth using vendor certs could be a strategy. Polycom yealink etc have vendor ca signed local certs and make this ca certs available for device level authentication. Seems like that could be a good way to cull the heard of BS traffic. Before the SIP server is engaged, cert auth happens first. Only valid SIP endpoints allowed. Niche hardware and soft clients could use certs from voip.ms.
It is a 100% packet processing issue - it is simply a matter of absorbing and processing a massive number of packets in less than 50ms at most - nothing else matters - the adding certs would only slow the process, I would think. You can pump the brakes on non-realtime traffic and not need as much raw processing power. The Magic Transit/Anycast product is really a cool solution.