I am not fully satisfied with the “buy more DIDs” and “send us all your addresses” approach to these 911 changes. So I’ve been polishing up some AEL-based dial plan called Always Be Conferencing which I outline in more detail via a FAQ on dispatchable location. I tested it on Asterisk certified version 16.3-cert1 but not yet FreePBX. Maybe y’all find it interesting (as the Asterisk forums are rather mute on the subject.)
3 Likes
Well I would suggest before you start pushing this to the public you have it reviewed by someone who knows the new laws. Based on what I am seeing right now I don’t think this meets the mark. It leaves quite a few questions that need to be answered.
I believe the biggest thing you need to verify is the fact that the PBX is the one answering the the 9-1-1 call and it’s not a real person. If I was to call 9-1-1 with this, it would dump me into a Conference Bridge and then attempt to make outbound calls to other people and the public PSAP. Now at this point you are no longer routing the call you are answering the call. You have the caller sitting in a conference bridge waiting for others to join them. Additionally the caller will have no idea who is joining the call. If for some reason the 9-1-1 operator isn’t the first to join the call, it can confuse the caller and make them think a 9-1-1 operator is there when they are not.
Even if the 9-1-1 operator is the first to join the call, others will join. Are they muted? Can they talk immediately? Will you end up with multiple people talking and confusing the operator? Who is the real caller? What type of confusion can this cause?
The notifications portion is meant to notify someone on site that a call has been made so they can meet the EMS and be their point of contact on the ground at the location. If the notice is sent to someone remotely they must have the ability to go to the location to meet EMS or have another point of contact.
So again, as it stands right now I don’t think this is a viable solution due to the fact it makes the MLTS (PBX) the one that actually answers the call then it is up to the PBX to initiate and then make the 911 call on behalf of the caller (along with other people) but while all this is happened this is an answered call with the caller sitting in a conference bridge with no other members in it. At this point along the call has failed to meet the requirements of the law.
1 Like
I’m going to say what I always say about this. Asterisk is not a PBX it is a toolkit. Asterisk is only a MLTS/PBX once you make it one. Therefore it doesn’t fall under the rulings of an MLTS on its own. I could setup Asterisk tomorrow to be a voicemail server or a conference server. These are not MLTS systems.
@BlazeStudios, did you ever see any sort of statement released?
Released by who and about what?
First, thank you for the feedback!
Is a more life-threatening issue the (occasional) lack of real persons at the PSAPs ? Here’s some two minute wait times, on 911, with modem noises and multi-lingual IVRs, from last summer on the shores of Silicon Valley.
ABC will start spooling the calls via Originate just before the OG caller enters the Conference Bridge. They and any friends on the call will continue to hear ringing until the remote answers eg. PSAP. So from their perspective the call is just “ringing” like it normally does, except now there are hopefully other (trained) people in your organization on the phone with you who can help you.
ABC is doing both routing and answering at the same time – they are not mutually exclusive. I considered a more routing-centric approach with the ChanSpy() application, bringing in extra local phones on the barge, but if the OG caller is disconnected, poof there goes the call. That’s bad. I think the call should stay up, even if the PoE switch stops PoE’ing the phone, so that front-desk and security friends elsewhere on the ConfBridge() can continue to talk to the PSAP, instead of leaving the emergency operator in the dark and forcing a call back.
Whether you wait in a ConfBridge() or a Dial(), the issue for the users is, still, waiting for somebody. ABC cuts waiting times, by routing the call better.
Well I can only hope the sysadmins testing it out don’t (immediately) turn it into a chat roulette wheel!
But there are some CONNECTEDLINE function calls in ABC that put the words “ConfCall” on the OG caller’s screen. Also there are Caller ID manipulations so the friends being joined in can see the extension number, caller name and the DNID, before they pick-up the call. (This could be further extended based on the type of phone eg. pop-ups in mini-browser on Polycom SPIP and VVX models.)
Or, it could save their life by getting somebody on the phone who can help immediately and may only be one or two floors or buildings away.
The solution envisioned with ABC is not entirely technical. It should be combined with user training, particularly for security personnel, along with some new reminder stickers on the handset/base, testing as in “fire drills” with 933, etc.
No.
Yes.
Possibly. But if the only friends you are bridging in are staff who’ve been trained on the ABC system eg. mental health, security, first aid teams, then I think they can do it without much confusion.
With training, I think it can help reduce confusion. For example, the * key maps to a ‘bot’ playing back GPS co-ordinates into the call, as spoken audio. For the OG callers who can’t speak, this is an improvement, because the security team knows to press * to get these co-ordinates. (The # key shuts the bot up.)
Also I included a unique tone ditty ‘signature’ of sorts in some areas – this could be sprinkled more liberally throughout ABC so that those hearing these tones know what it is without having to ask what is going on.
As long as you include friends on site in your adaptation of this work, then I think ABC goes above and beyond this notification requirement. I also consider the phone call notification approach superior to email or text, although it could be combined with those (slower) methods in a future version.
I understand this is a different way of thinking about it, but I could find nothing in the law – IANAL BTW – which says “thou shalt not send 200 OK in response until the PSAP answers.”
And what if the PSAP never answers ? ABC can help you solve that problem.
That is what Dial() does all the time. Asterisk is a B2BUA.
With ABC, the OG caller and friends will continue to hear whatever is playing on the line at the PSAP eg. ringing, IVR, hold music, etc; while being able to talk amongst themselves eg. “hey while we wait for 911 let me send our staff doctor over, they are down one floor from you.”
I thought end of January Sangoma was releasing a statement of future updates to become compliant with the new E911 laws. Figured I may have missed it.
In the OP, I linked to an Asterisk forum post with a link to this:
1 Like
OK, I’ll try to address these individually.
Here is the thing with that. Your personal belief, opinion or views on the matter are irrelevant. What you think should be done or what you think is a better solution doesn’t matter. These are laws, they must be followed. Additionally, the goal of these laws is to reduce the things you just pointed out. To improve the network and response times. Part of the “on hold with 911” issue is due to the fact that many VSPs or installers are poorly educated in 911. They either program the PBX wrong or (and I’ve seen VSPs do this) the VSP will decide the amount of 911 calls isn’t worth the monthly costs of 911 location records and let the calls route to regional PSAPs. So there are times PSAPs are either trying to collect right information from the caller because it was presented wrong or not at all. OR they are trying to get information relied from another PSAP to them because the call was routed wrong.
That is not to say some PSAPs are understaffed and don’t have all the resources they need but again, these are trying to change that.
OK here I’m just going to be general.
The issue with this solution is that the caller is being routed to a Conference Bridge which means the call is ANSWERED not by a person, not by a PSAP but by an automated system that keeps the call internal. Yes, you are going to then use Originate to send more calls out to the PSTN such as the PSAP and other callers but that is only _after they are in the conference bridge.
So I’m going to stress this again, when a user dials 911 the MLTS should have a dial pattern that sends that call to a PSAP (private or public) which is staffed by live people who can answer the call. This solution does not do that. It literally takes the 911 call and routes it to an internal conference bridge. That’s it. That is as far as you need to get with this logic. It doesn’t matter that the MLTS will then initiate a second call because the original call has been answered by the PBX system.
Just in case I wasn’t clear enough already. ConfBridge() answers the call, doing a Dial() does not answer the call. That is the difference right there.
Look I was going to try to address all this but it seems you’re looking at ways to validate your solution without having the right knowledge to make that determination. So again, I’m just going to go back to what I said originally. You need to consult a legal expert that can tell you what the new laws cover and what you can and cannot do to comply.
Right now based on my experience in the industry and coming from it in Michigan (where 911 laws and rules like this existed before Kari’s Law / Ray Baum’s Act) this would not be viable.
Also how does this solution actually address Ray Baum’s Act and the Dispatchable Location? You still need to have registered locations to send to the PSAP. So either you are doing that by a 1:1 relationship of DID:Phone or your are using Dynamic Location Routing which would require additional settings by the rules of the 911 provider offering that solution.
And no, reading back the location to the 911 operator when they are connected to the conference bridge does not cover that. At all, in any way.
We also recently wrote a blog on this subject and offer a solution that does not require you to buy DIDs for every location and also does not require you to even use us as your main SIP provider. https://www.clearlyip.com/2020/01/13/karis-law-ray-baum-act-your-responsibilities-and-clearlyip-support-for-freepbx-and-other-business-phone-systems/
A recording of our webinar last week can be downloaded from here. https://training.clearlyip.com/sessions/e911-kari
I can tell you the amount of demand for this has been a lot as it seems nobody is offering a full solution that covers all pieces of the law without spending a lot of money buying DIDs and e911 for each one and provide all the required notifications and even hot desking apps on the phones to handle roaming users.
It goes beyond that. The actual MLTS and voice connection is a factor as well. Case in point, I have an entire subset of end users that have old Mitel PBX systems. These systems are unable to present unique CallerID per station/phone for external calls. Therefore, these systems have to be completely replaced. There is another set of users that while their PBX supports unique CallerID per station/phone, it is only 10-digits. So either you need a real DID or a faux-DID that you can use internally to map.
Of course the one thing that all these PBX systems have in common, they use FXO cards and FXS handoffs to the PSTN. That alone makes them unable to comply because POTS/FXS lines cannot support sending different CallerID’s over them. They need to invest in a PRI card and gateway or they need to go IP/SIP.
So there is more to all this then buying a bunch of DIDs or DLRs. There are people out there with systems that can’t comply or they have POTS lines because while they have two floors and 15 offices, they only need 4 lines to the PSTN.
ABC starts threading out the Originates before the OG caller enters the Conference Bridge.
It might be the case that implementing ABC moves your MLTS into the realm of an “emergency services service provider”… not exactly new tech I guess…
Do you want to conference the security desk in on each emergency call?
If supported by the emergency services service provider, you can configure the location policy to include a callback number with each emergency call. This number is then used by the provider to conference your organization’s security personnel into emergency calls. This conferencing can be configured in the location policy to be one-way (listen-only) or two-way (bidirectional).
I’ve not tested this Skype method myself, but it sounds like the conference call could start between the caller and security desk before the PSAP answers.
ABC is offering a nearly pure dial plan solution that does not (yet) include automated dynamic DID / call back number routing to the OG callers desk phone; instead it relies on custom internal dial plan and databases/files for that portion, but a generic update with this functionality is planned for a future release.
The latest ABC v16c does include preliminary support for some Geolocation headers per RFC6442.
Except in rural areas where E911 does not yet exist. Or there is a malfunction at the PSAP that prevents delivery of the out-of-band information stream from their cloud service provider. ABC solves those problems, arguably, in more compliance with the law’s intent - relaying accurate location automatically and as quickly as possible, in-band on the actual call audio streams. I could not find a prohibition on this method.
And what if they have a PRI handoff, how will those help?
There are exceptions in the laws for this. Again, please consult a legal expert before pushing this as a solution to the public.
ABC also stuffs GPS info into the Caller ID name sent on the outbound call to the remote end eg. “LAT39.588LON-105.644:orignalname”. It may be possible for businesses served by the same CO as the PSAP to co-ordinate propagating that information on emergency calls only. I am open to capping it at 15 characters but was trying to find a standard format because I’m not sure if somebody just saw “39.588 -105.644” it would make enough sense to enough people.
And there are also resilient technical solutions to the problems, from fine people like you and others on this forum, working together to help fix the flaws that the laws could not.
Thank you for your time today!
Also not a lawyer but it’s hard to see that this looks anything but very promising for a real world “first response” situation. It might well save a life when and where e911 response can be measured in “way more than a few minutes”.
Couple of macgyver thoughts :-
Having knowledge of whether the phone is tethered or not, it would make a very big difference, (I wonder how the lawyers will handle this one)
Hooking TTS (google or ibm for example) gleaned and pre-prepared from various legacy “text fields” into a readygoEXT201.wav file (saving responders the need to “get out their software”)
Pre-prepared bespoke GPS/WIFi triangulated coordinates per extension perhaps as a featurecode/speeddial on your android/ios device reasonably expect less than 2 meters.
Phones , hard or soft, with GPS embedded , probably cheaper than you might think
Nice work !! keep it going . . .
1 Like
If you are referring to Fixed vs Non-Fixed devices, then that has been covered. No-Fixed devices such as Hot-Desking and user roaming from location to location must have a method to update their 9-1-1 location record based on their location. This can be done multiple ways. For users that will have no fixed location, like a softphone on a mobile device, then that user/line can be routed to a regional/national PSAP so they can handle the routing. Much like non-fixed addresses (no postal record). These types of MLTS systems have two years to comply. As for Fixed devices, well that implies they don’t move regularly or at all. Those MLTS systems must comply within a year.
This may be a nice add on feature but it doesn’t comply. The Dispatchable Location must be presented to the PSAP when the call is connected. It cannot connect the operator to a prerecording that just reads it out.
So again based on what is presented as a solution it is not viable. The laws state that 911 not only must not have a prefix but it must route to a PSAP. The fact this takes the caller and puts them in a conference on the MLTS makes it a violation. The fact that the 911 operator is being connected to a conference bridge and not the caller, violation. The fact that the only Dispatchable Location option is a TTS file that reads back the recording, a violation.
I just don’t think this is an acceptable solution because it fails to follow the basic requirement of the caller being directly connected to a PSAP.
How many lawyers would it take to discover liability when the roaming user , although he must and does have a method to update, doesn’t actually rember to do it?
As Dickens wrote:-
If the law supposes that," said Mr. Bumble, squeezing his hat emphatically in both hands, "the law is a ass — a idiot. If that’s the eye of the law, the law is a bachelor; and the worst I wish the law is, that his eye may be opened by experience — by experience.”
Not many I would think. Since the user forgot to perform the action the user is liable.
Obviously you do not know how the legal system in the US works. They sue for any reason. If it’s not easy for a user to change location info or if they are not promoted to you will be held liable guaranteed. As someone who has been involved in well over a dozen lawsuits it doesn’t matter who forgot to do something. It’s all about who has money.
Just ask McDonalds and their hot coffee mess.
4 Likes
Tony is right - and wrong. He is right that if you have assets and there’s potential liability, you could be sued. He’s wrong about McDonald’s and their coffee fiasco. McDonald’s was clearly in the wrong there.
The solution to managing legal liability risks is both diligence and insurance.
You should do everything you can to comply with the law. You should go above and beyond the law and do everything you can to ensure that 911 works and your users understand its limitations. You should contractually obligate your clients to notify their users of the limitations of e911 and to indemnify you from lawsuits and liability if the phones don’t work. You should make sure your clients have insurance that protects it from negligence claims by its customers, and consider asking your clients to add you as an additional named insured to their policy. And you should buy your own insurance anyway.
Even if you comply with the law, if e911 doesn’t work right - for any reason - and the damages are high enough, you along with everyone else in the chain of potential liability will face a claim. State tort laws don’t required you to have broken a law to be liable. Virtually ever State imposes liability for negligence, which generally only requires that you have a duty to act competently, to have breached that duty, and to have caused damages. If e911 doesn’t work and someone doesn’t have a mobile phone as a backup, the claim will be made that you didn’t comply with your duty of care.
If you have insurance, your insurer will sort it out. If you have no assets, they’ll settle with you quickly. If you have assets and no insurance, you’ll be in trouble.
1 Like