why not move that SIP trunk elsewhere? Like Intelepeer or Vonage or RNG
or Sangoma or anyone who would handle the E911?
On 1/4/2022 7:07 PM, Aaron C. de Bruyn via VoiceOps wrote:
When I handed Comcast a list of phone numbers years ago, they said
there would be no problem porting them over or using them.
That was it.
Then after the service was installed, someone mentioned "a few of the
numbers will be RCF'd", but we wouldn't have a problem using them.
Then 3 months into using the service (after our cancellation period
expired and we were locked-in), we suddenly started having problems
with the RCF'd numbers being re-written.
No less than 30 calls to Comcast over the years has resulted in widely
different responses including:
* Ok, we just changed an option in the AdTran to allow you to specify
your own caller ID, everything should work now (it doesn't)
* Give us a list of phone numbers and associated addresses so we can
update our e911 information (they respond with "done!", not "we can't
set e911 for phone number xxx-yyy-zzzz)
* I'm going to escalate this (followed by nothing happening and the
case gets magically closed)
After talking with Comcast this morning, I had a rep send me what they
had listed for addresses associated with phone numbers...and
unsurprisingly found that they had reset everything to the address of
our SIP trunk service. None of our offices have valid 911 contact info.
They're allegedly in the middle of updating the list again, but I'm
not holding my breath.
It's Comcast's job to provide phone service and 911 routing for this
client. They shouldn't be re-writing anything. They weren't in the
beginning, but I'm guessing it has to do with STIR/SHAKEN. I'm
vaguely familiar with it, but I'm not a telco or a phone service
provider. Just someone they hired to clean up their FreePBX phone
mess. ;)
-A
On Tue, Jan 4, 2022 at 3:01 PM Paul Timmins <[email protected]> wrote:
I'm going to be the unpopular one here, and point out that Comcast
is not really responsible to route 911 calls for you when you use
numbers that they don't provide. For the cost of an hour of an
attorney's time, you could just set up trunking to basically
anyone else to handle those offnet/off circuit numbers and the 911
routing for those numbers.
On 1/4/22 1:30 PM, Aaron C. de Bruyn via VoiceOps wrote:
One of my clients has a large SIP trunk with Comcast based out of
Washington State.
They have all their offices across Oregon and Washington hooked
into a FreePBX phone server that is attached to the Comcast SIP
trunk.
911 calls *constantly* get misrouted to the local PSAP where the
SIP trunk lives.
I must have called Comcast 30 times over the last few years to
try and get this addressed, but Comcast flat-out refuses to fix
the issue.
The short answer is that Comcast refuses to fix it. In some (but
not all) cases, our phone numbers are RCF'd numbers, so they
don't actually exist on the trunk...and Comcast forcibly
re-writes them to our 'main' number...and then routes the 911
call incorrectly. In other cases, we have provided Comcast with
the e911 information, they say it's updated, and then we find out
months later (when an office dials 911 during an emergency) that
it's still not correct.
Not only does this affect 911 calls, but also customers who get
the re-written caller ID and have no idea which office called them.
The "easy" solution is to ditch Comcast and move to a provider
that doesn't play the RCF and caller-ID-rewrite games.
Unfortunately my client is locked into their Comcast contract for
another ~18 months. Early termination would incur a ~$35,000 bill.
Is there a list of PSAP numbers somewhere so I can set up an
internal redirect to the PSAP 10-digit number? I know those
10-digit numbers are guarded like Fort Knox, so I'm betting this
option isn't very realistic.
Maybe a separate service provider that can just handle 911 calls
without "owning" my client's phone numbers?
Any other thoughts on how I can route around Comcast brain damage?
Thanks,
-A
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
