Of course! Thanks for pointing it out though. The automated notification and the designated recipients are pretty straight forward to setup in FreePBX. I just hadn’t heard of a way to implement the dynamic E911 based on extensions for outgoing 911 calls, so was curious who else might provide this functionality.
Thanks for the comments as well, really appreciate the thoughts from someone with some solid experience!
The laws have nothing to do with the provider routing the call. It’s about the PBX/MLTS system that you are in charge of. Of course if the carrier is having issues that’s not your fault. Not having the PBX programmed properly? Not submitting the proper records to 911? Those are on you.
The laws make the PBX Installer/Admin responsible. Not just for programming the PBX but you can’t install PBX systems that don’t have the ability to comply with this. Nor attach it to services that can’t support this.
A lot of hotels, for example, use POTS lines because they don’t have that many calls. POTS style services (analog or VoIP) do not support letting 100’s of different CallerID’s be set the user side. So hotels now need a SIP Trunk or PRI/T1 that allow this to happen.
Let’s also keep in mind the initial fine is $10,000 with a $500/per day tact on the PBX is out of compliance. And yes, they will go after the installers/admins.
My solution watches the ‘full’ log, emails here but whatever get done immediately on the call being dialled, it does not depend on an answer, ringgroup or any other machination, (of course it does depend on a network connection.)
tail -F /var/log/asterisk/full|while read LINE; do if [[ $LINE =~ \[911@from-internal:1\] ]] ;then echo $LINE|mail -s "oh shit, call the big red truck!!" [email protected]; fi ;done &
(well actually that is just one instance of a ‘case’ statement that also catches other significant calls )
I don’t think what the law is, is in question here (at least not for me, I understand it). Apologies if I mispoke, I was referring to the carrier when I said “provider”. Of course, if the system your managing is not correctly configured, that’s you’re fault. I wouldn’t think anyone would assume otherwise. I appreciate the follow up!
(apologies again if I misunderstood your objection/clarification!)
@BlazeStudios we discussed the building requirements for your state earlier in the year, I suspect that is what you are thinking about. Telecom Industry Changes - Kari's Law / Ray Baum's Act / STIR/SHAKEN / TRACED Act
Since more than 20 states also have their own requirements, it is difficult to deliver blanket assessments of what is needed. From a Provider View we have attempted to build the strongest solution that covers both the notification requirements for Kari’s Law, and the Dispatchable Location requirements of the Ray Baum Act, well before the actual drop dead dates on enforcement, in a flexible and very affordable price point.
In my opinion, anyone installing systems today should provide solutions that already cover these requirements, not only because it is safe and appropriate, but also because who wants to do the setup twice.
Yeah, I thought that was talked about in another thread. I mean for the most part a lot of my office based customers are fine with a single location. Office is small enough, one egress and there is always someone around that area to deal with EMTs. However, I do have multi-floor / multi-room offices so they need it.
First props to Sangoma for not flagging this thread of discussion about their competitors, as I believe Sangoma does offer these services.
Quoting OP:
Those rooms aren’t moving around the internet, so why send the emergency phone call around the internet ? (Except maybe for remote learning situations ?)
I would recommend also quoting out local PRI T1 vs. local SIP from the ILEC vs. far-away SIP providers, along with written guarantees about the address/room update process charges, and then asking if that price difference is worth the trade-off you get from the potentially more direct path of: School → Central Office → PSAP (vs. School → Cloud Internet → PSAP.)
This would then require a PRI/T1 card for the PBX or a gateway to do the conversion. As well most LECs are delivering PRI/T1 over IP and converting at the location for the PBX handoff.
CLECs yes – so buyer beware of what you quote/compare/order! – but the ILECs underneath those CLECs are often doing so with data T1s from CO to demarc (at least in the case of sufficient existing capital eg. older buildings with copper wires.) That the CLEC does VoiP on top of the ILEC infrastructure is something then for the CLEC (and end customer) to worry about.
CLECs do everything on top of the ILEC infrastructure unless the CLEC has built out their own (which is rare). That means POTS, T1, PRI, T3’s and so on. Now if it’s data and/or voice being serviced over those connections that’s on the CLEC. However, if there is something physically wrong with the circuits the CLEC is going to open a ticket with the ILEC to fix it because it’s their infrastructure.
Back on topic.
Without actually knowing what ClearlyIP is doing, but assuming a few things based on what I do know about general infrastructure.
When a 911 call is dialled, the only information going to the PSAP is the CID.
The PSAP system will then initiate a lookup to the ALI (Automated Location Identification) database.
I assume that, as the 911 called is dialled, ClearlyIP is sending an update to the ALI.
The ALI database and the PSAP systems are the part I don’t trust to work reliably with those updates.
I trust the ClearyIP code to send the information.
I do not trust that the subsequent pieces will update in real time.
You are 100% wrong on how we do this. The data is stored just like traditional 911 and we don’t send CID to a PSAP. That is not how 911 works. They receive all the 911 info the exact same way they have since e911 was introduced.
Am I understanding the clearly IP 911 service correctly in that it’s 50c per location and I don’t need to have the DID and sip trunking service with clearly ip?
No, you have to have their trunk to use the location services. You do not to use their trunk for anything other than 911 though.
Only the provider can maintain the verified address of the caller.
As I said above I trust their part of the service 100%
This isn’t actually a 100% accurate. I’ve gone through the process (have a NENA number and all) and if I wanted to I could do off-net 911 services. Allowing me to provide E911 for numbers from other carriers. Others can do this and are.
Here is a video we did back in March where @tonyclewis goes through how we do e911, and a breakdown of Emergency Call Back Profiles and Dispatchable locations: https://youtu.be/bndYzTPHMe4?t=449
He also covers how we handle e911 within our Clearly Anywhere applications for Android and iOS in this webinar: https://www.youtube.com/watch?v=qQco05RaPgE&ab_channel=ClearlyIP
This is really helpful. Thanks for sharing.
@BlazeStudios We just had a chat with BW regarding E911 and ClearlyIP (they mentioned ClearlyIP might even get their E911 service through BW, but this was not confirmed, so no clue, may have just been sales smoke). Their non-blended rates seem great as far as I can tell, our average is in the $.00045/min range vs Flowroute’s $.007/min blended rate.
So what we’re leaning towards now for trunk configuration is:
Bandwidth (Main provider, in/out)
ClearlyIP (E911 provider, in/emergency-out)
Flowroute (Failover, out)
+1 for bandwidth.
Wow, that seems too good to be true. Can you please give specific examples e.g. VZW in a major city? What monthly commitment is needed to get those rates?
That sounds like marketing not technicaling. 
There is at least some difference in how the data is getting pushed because the starting point is different.
But you probably should route some other calls through it regularly and alert if it goes down because you don’t want to find out the SIP registration failed after the 911 call failed.