There have been quite a few topics that have trailed off into talk about Kari’s Law and Ray Baum’s Act so let’s do it here. It also seems that the focus is mainly on the notifications part, which while its grey area-ish, it is the one part that has the more leniency compared to the rest. So let’s cover some things.
Station = Endpoint/Phone/Device that dials.
Anyone must be able to pick up a phone and dial 9-1-1 without any prefixes or special codes to initiate the call. This is supported in FreePBX.
What this means: The installer/maintainer must program the PBX to support this.
9-1-1 must be routed to a 24/7 staffed destination. This does not require the destination to be the PSAP.
What this means:If you have, let’s say, a Health & Safety station that is staffed 24/7 with first aid responders, 9-1-1 can be set to ring their station(s) as long as a live person answers the calls. It cannot go to voicemail or another alternate automated destination.
Stations must present their detailed location information when 9-1-1 is dialed. This is regardless of an internal (as in item 2) or external (PSAP) destination. There are caveats to this such as Residential houses regardless of levels and small single level buildings can present a general location for 9-1-1.
What this means: As the installer/maintainer you must make sure that each extension in FreePBX has the Emergency CallerID field set to show the proper station details. This could just be the default station CallerID or a unique DID. FreePBX supports either.
The presented CallerID must be a valid dialable number that can receive call backs.
What this means: When 9-1-1 is dialed and the CallerID is presented, internal or external, the destination answering must be able to return a call to the caller if they are disconnected for any reason. So if the call is going to a PSAP then the number presented must be routable back to the caller.
Outbound/Internal only stations, i.e. they don’t receive inbound calls or have no ability to call the PSTN, must still support dialing 9-1-1, present the station CallerID location and be able to receive an inbound call for 9-1-1 purposes.
The above items cover what is known as the “Dispatchable Location” and new installs will require this after Feb 16th 2020. Most current PBXes support these abilities, including FreePBX, which is why these items are the onus of the installer/maintainer. So if for some reason you are installing a PBX system that can’t support this, you need to stop installing that PBX system.
Now in regards to the notifications, as the installer/maintainer there is zero expectation/requirement for you to modify the PBX hardware/software to support notifications. Kari’s Law puts the onus of that on the makers of the PBX that new systems they introduce to the market after Feb 16th 2020 must support notifications.
While all that is happening there is now Ray Baum’s Act that states existing systems must comply with Kari’s Law with 1-2 years of Kari’s Law being signed into law (so Dec 2019 which means at the latest Dec 2021). They figure that is enough time for businesses to come into compliance.
As written, this implies that the return call must be routed direct to the original caller meaning every dialable device in the USA needs a unique DID.
I’m still getting clarification on it but I believe that it is acceptable to have to call routed to the designated contact. As part of this and the whole notifications thing, there seems to be an expectation that each business/location would have a contact person. This is why the notifications are being made a requirement. That contact person may or may not be onsite and if they are remote they must be alerted to all the details and be available to meet EMS at the location if needed.
So yeah, I think of you were made the contact at the Sangoma office, then the call back can be routed to you as you should be alerted and with EMS with they get there. But like I said, still waiting for clarification.
And for anyone thinking there isn’t much to this, take 10 minutes to ponder the hotdesking and mobile client cases. About 10 min is all it takes for the headache to start.
As I just pointed out, Hot Desking is for the user the actual phones they log into are still the station/endpoint and have their own ID so yes, regardless of what user is logged into it the station should be able to present its ID.
As for mobile phones, yeah I’m not sure. My expectation is that if I’m out and I need to call 911 from my mobile, I’m not bringing up Bria to do it. I’m just hitting the “Make Emergency Call” option or straight up dial 911.
Additionally, is there any plans from Sangoma to address the issue of users who use Hot Desking between different locations to somehow update the Emergency CID based on the location where the extension is logged in?
I’ve never used User/Device or a lot of Hot Desking so I would need to look closer at it. I’m going to guess that a lot of it is done at the system level and while the phone template may update to show your BLFs, softkeys, etc the SIP creds don’t change and calls are just routed to the device.
If that is the case then when that device sends 911 to the system, regardless of the user that is logged into it, it will know to set the specific CallerID for that station not the user.
I am also not sure how hotdesking works within FreePBX. But with the phone apps and Sangona phones, it is your extension that follows you around. So while you may have a valid call back method, the location tied to the DID that the extension routes out will be wrong if you are logged in from someplace else.
How I understand these Hot Desking with phone apps work:
That once you sign into on a new device, the SIP session is being remove from device 1 and then set to just a keep a provisioning connection to the PBX so you can login a different extension, and device 2 is downloading the SIP and template info that was until now on device 1.
So, if no one is logged into device 1, you can try dialing, but there’s no SIP connection between this phone and the PBX.
I actually started to write this a bit ago but then had to deal with something and then started replying to the other comments. There are some other areas that should be addressed.
POTS line will no longer be viable for PBX systems that need to comply with the new laws. The service isn’t designed to support it. So not only will the PBX need to support “Dispatchable Location” the voice service needs to support sending multiple unique CallerIDs for this to happen. Meaning that they would need to convert to SIP or PRI/T1 to support the regulations.
There are still PBX systems out there that cannot support Dispatchable Locations/presenting a station based CallerID. So there is an opportunity here to help people come into compliance over the next 24 months.
I think that this (above) is the real problem with the new legislation. But, it was also a problem with the old regulatory scheme that required that all devices to support e911 and send their address.
Because following the law is critically important in my line of work, I deliberately avoided configuring hotdesking and mobile devices because I could never find a way to reliably comply with the existing e911 requirements.
For mobile devices that have SIP clients, it may be enough to simply ensure that 911 calls are routed over the wireless carrier and not using the SIP application. Then again, it might not be.
If you guys are concerned about this, I strongly suggest that you have your lobbyist submit comments to the FCC (or that you do so yourself).
Small offices that have their operation in a single suite can probably continue to use POTS lines. A larger operation that uses multiple floors could get away with it by ensuring that each designated area has its own POTS line designated for 911 dialing. It would definitely be easier for both to switch to some kind of digital line.
I don’t think you’re correct for the reasons that I’ve said before in another thread. I see nothing in Kari’s law that puts the onus on PBX makers to support notifications. Regarding notification, the only obligation that I can see is that the installer must use the feature if one is present. And the notification can come from any point in the system, which I believe can be the ITSP.
The President recently signed into law two statutes directed to the improvement of 911: (1) Kari’s Law Act of 2017 (Kari’s Law), which requires implementation of direct 911 dialing and on-site notification capabilities in multi-line telephone systems(MLTS)
Perhaps you should give the below a read from back in Sept. It should be noted that 23 states in the US already have rules about direct dialing and notifications. Numerous systems already support both features.
It’s also been covered that if a minor update to the system due to routine maintenance and system updates count as making the system compliant. Since a system like FreePBX already sends alerts and emails for numerous things then supply an update to like the Framework module to send 911 alerts would be something they would need to do because it doesn’t fall under a significant or major updates to the core system or programming.
You should also understand that there is language in the law that defines someone in the “business of installing MTLS” as person that engages in the installation/management of the MTLS including but not limited to connecting it to the PSTN, connecting phones, setting up call routing patterns, call flow, etc. So it doesn’t matter if it’s your business in the sense of you’re doing it to make a profit or anything off of it, it is the fact you are engaged in the activity.
Modified the subject a little more to cover the broader scope of changes coming. Mainly to bring STIR/SHAKEN and the TRACED Act into the fold.
The short of it is that STIR/SHAKEN will be put into place to validate the calling party and to combat CallerID Spoofing and fraud calls. This works in various steps first being that the end user (the PBX) will need to validate their CallerID with their provider and then their provider will sign that call to send to the destination to allow all parties involved to know the CallerID is valid.
It also states that callerID must be in a 11/10 digit format for those using NANP (NXXNXXXXXX) and International must be in the valid International format. It must also be a valid regional number so things like 2002000000 would not work or 9999999999. Some places are already starting to enforce this and those with iNum numbers (non-geo specific International numbers +883-5100-xxxxxx) are failing to go through because that block isn’t considered valid in this case.
While STIR/SHAKEN is still being adopted, TRACED Act states that it must be in place by July-ish 2021 giving everyone 18 months to make it happen.
I’ve read it, and I don’t see the language supporting your statements. Would you please cite the page number and the language in this document that you believe supports your position (1) that PBX manufacturers have an obligation to provide notification capability (as opposed to 911 dialing) and (2) that hobbyists qualify as persons “engaged in the business of . . . .”?
Not to come in here and over promote something from us but this is something with Clearly IP Phone we have solved and we covered in our webinars this week we gave. We have the ability when a user logs out of our phones, you can have it default to a under the covers extension that is setup to allow 911 calling along with our new 3 prong notification system that includes paging, email and/or SMS to solve the issue of each extension does not need a DID as the call back can go back to the front desk as long as the front desk is notified of who made the 911 call.
The other big point here is the requirement that the person calling 911 transmits location within the building meaning it can not just be the address anymore. It has to be something like 1st floor northeast corner or 2nd floor main conference room or in the case of schools and hotels the classroom number or hotel room number has to be sent to the PSAP. This gets very expensive quickly buying e911 and DIDs for every extension. Stay tuned for a blog coming out this week from Clearly IP on a brand new Dynamic Location 911 service that we are launching publicly next week that we have been working on.
We also have the ability for users who physically move the Clearly IP phone around that when the phone boots it will prompt them to verify which location they are at with a list of locations that have permissions to choose from.
The problem with that is how does the ITSP know which user called. The PBX hides that from the PSTN. The only way it would know is if you bought a DID for each extension and e911 on each of those DIDs which gets really expensive quickly. Only the PBX knows which user/extension made the call.
The answer is virtual DIDs used for e911 purposes.
Let’s say that my DID is 212-555-1212. And let’s say that I have four dispatchable locations at that DID. We’ll call them location 001, 002, 003, and 004.
When I activate e911 with you, I’ll program in the four locations and their assigned numbers.
So, when I activate e911 for 2125551212, I’d enter in the following additional information:
Location 001: Front Desk
Location 002: Warehouse Floor behind Front Desk
Location 003: Second Floor, conference room
Location 004: Second Floor, Office of Tony Lewis.
Then I’d program my emergency CIDs for extensions in each location. In location 001, it would send
2125551212001
In location 002, it would send:
2125551212002
In location 003, it would send:
2125551212003
and so on.
When you get my 911 call, you’d look at the CID, decipher the location, send the call to the PSAP along with the appropriate location information.
Viola!
Now to support the call-back ability, you might require real DIDs. I haven’t read that section carefully yet.