[VoiceOps] Misrouting 911 Calls?

Mon Jan 10 10:16:22 EST 2022

In my case, I doubt it.  I'm not a phone company or VoIP provider.
I was simply called in to help them with their existing VoIP server (among
other things).

-A

On Sun, Jan 9, 2022 at 7:47 AM Mike Hammett <voiceops at ics-il.net> wrote:

> Are you potentially underestimating what you're required to do for 911?
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
>
>
> ------------------------------
> *From: *"Aaron C. de Bruyn via VoiceOps" <voiceops at voiceops.org>
> *To: *"Mary Lou Carey" <marylou at backuptelecom.com>
> *Cc: *voiceops at voiceops.org
> *Sent: *Saturday, January 8, 2022 5:11:36 PM
> *Subject: *Re: [VoiceOps] Misrouting 911 Calls?
>
> I filed a complaint with the FCC about a year ago.
> The FCC reached out to Comcast and Comcast reached back out to me.
> Their response was that we would basically have to purchase ~200 numbers
> (one for each extension on our system), set our outbound 911 caller ID to
> those numbers, and then provide Comcast with a list of mappings between
> phone numbers and addresses.
> It would have added a huge tracking burden for IT as well as increased our
> bill by about $2,500 over the contract term.
>
> It's all moot now as BulkVS cost less than $50 to set up, we've already
> had one successful 911 call from an office that was continually misrouted
> by Comcast, and the contract is up "soon".
>
> -A
>
> On Sat, Jan 8, 2022 at 2:37 PM Mary Lou Carey <marylou at backuptelecom.com>
> wrote:
>
>> I was just going to say the same thing. If you give Comcast or any
>> carrier a chance to fix it and they can't/won't/don't, then you have to
>> escalate it above their heads.
>>
>> The 911 network has always operated separately from the PSTN world for a
>> reason. That's because misroutes can result in people dying! Carriers
>> can get in HUGE trouble if they don't address routing issues immediately
>> and VOIP carriers can also get in trouble if they don't allow the
>> customer a method of updating their location themselves.
>>
>>
>> MARY LOU CAREY
>> BackUP Telecom Consulting
>> Office: 615-791-9969
>> Cell: 615-796-1111
>>
>> On 2022-01-05 09:08 AM, Mike Hammett wrote:
>> > Escalate to the PUC and ETSBs.
>> >
>> > Unfortunately, with companies like that, honey doesn't work. You need
>> > vinegar.
>> >
>> > -----
>> > Mike Hammett
>> > Intelligent Computing Solutions
>> > http://www.ics-il.com
>> >
>> > Midwest Internet Exchange
>> > http://www.midwest-ix.com
>> >
>> > -------------------------
>> >
>> > From: "Aaron C. de Bruyn via VoiceOps" <voiceops at voiceops.org>
>> > To: "Paul Timmins" <paul at timmins.net>
>> > Cc: voiceops at voiceops.org
>> > Sent: Tuesday, January 4, 2022 6:07:52 PM
>> > Subject: Re: [VoiceOps] Misrouting 911 Calls?
>> >
>> > 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 <paul at timmins.net> 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
>> >>> VoiceOps at voiceops.org
>> >>> https://puck.nether.net/mailman/listinfo/voiceops
>> >>
>> >> _______________________________________________
>> >> VoiceOps mailing list
>> >> VoiceOps at voiceops.org
>> >> https://puck.nether.net/mailman/listinfo/voiceops
>> >
>> > _______________________________________________
>> > VoiceOps mailing list
>> > VoiceOps at voiceops.org
>> > https://puck.nether.net/mailman/listinfo/voiceops
>> > _______________________________________________
>> > VoiceOps mailing list
>> > VoiceOps at voiceops.org
>> > https://puck.nether.net/mailman/listinfo/voiceops
>>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20220110/d9513e45/attachment-0001.htm>