Alternative solutions for new E911 rules in 2020

I will have to look at it again. Based on a quick glance it doesn’t go to the conference bridge until after the PSAP answers, however, that still dumps the caller, Operator and N “friends” into the call. So it still can raise confusion and issues.

But again, any MLTS vendor is going to have to provide a method for this. Not all will have the same, the need to install a third party solution isn’t going to exist. That said, the desire or preference to do so can be totally there. Just as you noted with your preference.

My last couple queries actually have nothing to do with how it works or what it can do or any of that. To recap those where:

1.) Since this will be the defacto thing all MLTS systems will have. How will the OP make his solution something people want to go after and use when many already have their needs covered?

2.) How is the OP going to support this? So far it doesn’t seem there is any. This is supposed to be a solution to regulatory and legal requirements. Support for this is going to be expected, so what is the answer for that?

Actually, this ruling, unlike previous FCC rulings on things related to 911 is very much not specific for many parts of it.

This was what I found to be the case. If the letter of the Law mandates that security personnel must be alerted that a 911 call was placed so they are also aware of the caller, I just placed this in the extensions_custom.conf. Maybe that’s overly simplistic, so I’ll pass this by our legal team.

`[macro-dialout-trunk-predial-hook]

exten => s,1,ExecIf($["${OUTNUM}"="911"]?System(echo "Ext ${AMPUSER} - ${AMPUSERCIDNAME} just placed a 911 emergency call on ${STRFTIME(%C%m%d%y%H%M)}" | mailx -r "[email protected]" -s "911 Alert from ext ${AMPUSER} - ${AMPUSERCIDNAME}" [email protected]))
exten => s,2,ExecIf($["${OUTNUM}"="933"]?System(echo "Ext ${AMPUSER} - ${AMPUSERCIDNAME} just placed a 933 test call on ${STRFTIME(%C%m%d%y%H%M)}" | mailx -r "[email protected]" -s "933 Alert from ext ${AMPUSER} - ${AMPUSERCIDNAME}" [email protected]))
exten => s,n,MacroExit()
`

Then I already have DID numbers associated with desk phones. So I just converted them to Enhanced DID with my provider and assign their e911 location to specify their floor, room number, etc. And defined an Emergency Outbound route for the site, with each extension defined against those Enhanced DID’s for their respective Emergency Caller ID.

Didn’t need to ignore a leading 9 to get out since we had no prefix required to get an outside line anyway. So that was a non-issue.

The total time it took to implement this was maybe an hour. Not sure why an over-engineered solution is required. But then again we didn’t have to worry about analog lines, roaming SIP users, etc. And I still need to run this by legal…

SMS might meet the letter of the law, but I would never rely on it as the only thing.

1 Like

Good point.

What’s ironic is with the prevalence of cell phones, how much attention still has to be paid to legacy technology. For example, I administer five company sites that are tied into a single IP-PBX. The most concurrent calls (other than a reporting anomaly) we’ve had across all of them is twelve calls looking back over the past 2-3 years. Back in the days of a PRI into our main office alone, we’d often exhaust 23 channels during the busier times of the retail season.

Still having to support elevator emergency phones auto-dialing 911, support independent copper POTS alarm lines for the security alarm panels for U.L. insurance requirements, support copper POTS faxing for international vendors where analog FXS and T.38 don’t cut it, etc. is a throwback. And this is coming from someone who cut their teeth on Merlin Legends, Nortel Meredians, and Rockwell Spectrums. :joy:

I realize that cell phones and 911 aren’t always a winning situation. But in the year 2020, if I were having an emergency and was physically able to communicate to someone, I don’t know why I wouldn’t just grab the phone in my back pocket. But the law is the law and the FCC are the FCC.

1 Like

Example #8 from ABC v16g highlights only slightly more functionality than what Sangoma’s Outbound Routes+Notifications+Paging configuration currently offers in regards to notifications - except - you’ll need to change some #XYZ# type variables and use Misc Destinations because ABC is not a "Free"PBX module…

;
; Example #8: Trolls auto-answer in half-duplex AKA "Page Group"
; --------------------------------------------------------------
; * In Tin Can Mode (Yes, Again)
; * Trolls only. They can not talk to anyone in the YURT.
; * Add "nosy" to troll if they should listen to call.
;   (Without "nosy" option they will just hear an announcement.)
; * Choose caller ID based on subnet ID.
; * Defaults to FreePBX emergency CID if no subnet override CID is found.

[from-internal-custom-abc-example-8]

exten => s,1,NoOp()
exten => s,n,NoOp(placeholder)
exten => s,n,Log(VERBOSE,Always Be Conferencing - PenguinPBX.com)
exten => s,n,Set(cidnum=${FILTER(0-9A-Za-z,${CALLERID(num)})})
exten => s,n,Set(defaultcallback=${DB(DEVICE/${cidnum}/emergency_cid)})
exten => s,n,Set(ABCTO=${CALLERID(DNID)})
exten => s,n,Set(path=SIP/${ABCTO}@#SIPTRUNK#)
exten => s,n,Set(troll1=SIP/#FRONTDESK-EXTENSION#)
exten => s,n,Set(troll2=SIP/#OVERHEADSPKR-EXTENSION#)
exten => s,n,Set(abctypename=sbnttrl)
exten => s,n,Set(pathringtime=120)
exten => s,n,AELSub(pngnpbx-abc-tincan,${abctypename})
exten => s,n,AELSub(pngnpbx-abc-path,1,${pathringtime},${path})
exten => s,n,AELSub(pngnpbx-abc-remote,${defaultcallback},subnet)
exten => s,n,AELSub(pngnpbx-abc-troll,1,${troll1},nosy)
exten => s,n,AELSub(pngnpbx-abc-troll,2,${troll2},)
exten => s,n,AELSub(pngnpbx-abc-howdy-yall)

…but by changing that first Troll to non-nosy, and removing the caller ID based on subnet ID, then I think the functionality would be pretty much the same for non-hot desking situations. (Maybe add another “path” for backup.)

Short answer is yes, that bureaucratic ball is rolling along. What I’d really like in an upcoming ABC version is to be able to say “Example #10: Approved by Vogon Captain Jeltz” :slight_smile:

BUT I AM NOT A LAWYER, and many State and Local governments mandarinate different approaches than what the Federal government is only just about to start doing this weekend on new installs. So this is an on-going effort, with very little case law - we are all working with eight week old FCC rules not yet tested in court. But I’m also talking with PSAP operators, trainers, first responders, NENA, etc., and reviewing their information. It is quite fascinating and IMO the entire industry is ripe for disruption. Asterisk is playing a role in this - see this job listing snippet:

Solution Architect - Telco Systems and Networking
Motorola Solutions Birmingham, Alabama, United States
7 days ago 

Qualifications:

* At least 5 years experience in telecommunication systems and networking
* Knowledge of Cat5, Cat6 and Fiber cabling including installation and troubleshooting
* Experience with SIP based communications with Asterisk

In that vein, maybe you’d like to help nominate me to the NENA NG9-1-1 Interoperability Oversight Commission ?

I personally don’t think the FCC is authorized by the US Constitution to even exist. But these two things in Kari’s Law seem somewhat reasonable:

Also I can help repeat this question…

…but if the answer is “yes, legal” to what Sangoma put out Monday, and in a slightly degraded mode ABC does basically the same thing, well if it quacks like a duck…

This is on top of all the other processing that happens in the FreePBX dial plan to get you to that point. ABC side-steps much of this. So it might be the case that ABC is actually faster. I don’t know. It needs testing.

ABC can do both and much, much more, at the same time.

In ABC, Trolls can be nosy or non-nosy. Nosy Trolls listen using mute-only ConfBridge. Non-nosy Trolls just hear an announcement eg. “922 call from 1234” and then it hangs up. This is highlighted in the Example #8 above.

This non-nosy option may be useful in some environments where it is prohibited to listen to the ongoing call, perhaps owing to two-party consent requirements in your locality, or other privacy concerns. (However, emergency calls to PSAPs are generally recorded without any sort of notification as I understand it - I was designing ABC to be more flexible, although adding the call recording beeps is on my TODO list for future versions.)

I agree. That is what ABC is designed to do in Tin Can Mode. The bridge only happens instantly with the caller when in Simple Mode.

The confusion can be dealt with by training the Friends ahead of time.

I am not certain, but I think the same criticism can now be leveled against the Sangoma solution posted on their wiki from this other thread on the forum, when the Page is operating in Full-Duplex. Also if you do not specify any “Friends” in ABC, that is okay – it will work with just nosy Trolls listening in but unable to talk (again please see Example #8 above.)

From the Sangoma wiki:

You can set up Notifications on Outbound Routes by linking a page group to an outbound route. If a call is placed using that outbound route, the phones in the page group will be paged with an announcement of the extension number that made the call, and the number that was dialed. Assuming the page group’s Duplex option is set to No, the phones in the page group will then be injected into the call in a listen-only mode.

ABC only works full-duplex with “Friends” and always half-duplex with “Trolls”. But you can mix-and-match Friends, Trolls and Paladins on the same call flow. (Paladins get their own conf bridge spawned dynamically - the Palace - while Friends and Trolls stay in the Yurt.)

I don’t think that is how markets work. Also ABC does not require FreePBX. It works with Asterisk all by itself.

I hope the discussion here brings focus to the differences between solutions. Each user is unique, with different needs. Maybe ABC is a better fit for some cases and not others. Up to you!

Anybody who can download ABC can theoretically provide support for it because it is Free Libre Open Source Software.

I would encourage offering up some of the ideas from ABC for discussion with your team and letting us know what you find out. ABC does support email notifications, but when I present the “it sends an email when you call 911” approach to lay-persons, particularly those with full inboxes, I invariably get back wry chuckles. But it is considered sufficient by many.

Although that choice is outside the scope of ABC, and yet totally compatible with ABC, this threat to privacy drives many of the decisions in ABC, specifically those related to Dynamic Location Routing. I do not consider it safe to pre-publish all of this previously un-published internal confidential company information. I do not think the map to critical infrastructure should always be turned on - and neither does any facility manager that requires you to turn off your cell phone before you walk in the door.

Liberty is hard.

ABC offers SMS/Email/Voicemail notification support using your existing voicemail.conf, in addition to the Conference Calls (Friends, Paladins) and Page (Troll) options.

Maybe archaic but the most accurate Dispatchable Location information is probably still that which is paired to a physical residential phone line from the local telephone company. For children or others without cell phones, it might be the best option.

Thanks y’all for the feedback!

Honestly, I don’t care what your solution can do. How many forms of notifications it can do. How many ways it can conference calls together or do TTS. You still haven’t answered probably them most important question I’ve asked so far.

How are YOU supporting this solution for regulatory and legal requirements? As an end user of your solution, what kind of support can be expected?

That’s too bad. :frowning:

Great questions!

The answer: it varies!

But absent any contractual or other legal obligation between us, of course ABC being FLOSS released under CC0 license is your free gift with no support by default, although I am trying to help answer as many questions as I can (in this thread for example.)

Although not my work, I do like some of the wording on Page 7 from this document:

Including:

Company acknowledges and agrees that it is Company’s sole responsibility to ensure that the Supported Software and associated networks and systems are implemented and configured such that emergency calls are properly handled, that any system or application based on the Supported Software complies with all applicable laws and regulations; and that Digium has no obligation or liability for performing such services under this Agreement.

And:

COMPANY EXPLICITLY RELEASES DIGIUM FROM ANY LIABILITY

…on it goes. So you might expect something similar.

OK, so the bottom line your solution for federal regulatory and legal requirements has no warranty, no guarantee and no support. It is basically amounting to some code on an enthusiast/hobbyist VoIP blog.

And you actually want people to choose this over their manufacturer’s built in option? More power to you.

If such options exist… And only after people learn how ABC is technically superior to most alternatives currently on the market, and they explain how they plan to use ABC to their legal team, and they get approval from their legal team, and they fully test and properly configure ABC in their environment, train their users, etc., then yes I think it could help save lives when seconds count.

At a minimum, I think some of the goals of ABC were already accomplished with the Page Pro re-release as “free” software from Sangoma – not taking credit for that decision here, but that choice did implement some of the ideas demonstrated concretely earlier in ABC as discussed earlier in this thread. (Previously the Notifications on Outbound Routes were limited to commercial Page Pro module users.)

And I am perfectly happy if manufacturers’ built in options end up looking like… ABC. :cowboy_hat_face:

No, more power to the users!

( still looking for any guarantees and/or warranties published by ANY ‘player’ yet :wink: )

Besides hardware, I can’t find any either on this site…

And I thought the CC0 license was clear enough on this, but I added explicit NO WARRANTY notices in the latest version of ABC v16h “Human Action Edition”.

Additional improvements include:

  • Use of Plus codes as well as standard GPS latitude and longitude.
  • Fixes to start of answer TTS of GPS announce mode (was broken in v16g.)
  • Usability improvements for the DIY GPS IVR including Plus code capture.

Per the Plus codes, I stumbled on these and, natch, now they keep popping up - sometimes in very related contexts such as the Android TTS location features in 911 calling mode. But given that plus codes are at most 11 alpha-numeric characters, I think they could fit into “standard” Caller ID name mappings quite well, potentially allowing another way to automatically get dispatchable location information relayed to PSAPs using PSTN tools already widely available.

1 Like

(liking “Plus Codes” If Amazon and FedEx used them I personally wouldn’t get so many 'un-deliverable package" notices. ) And way less obtuse than what3words.

I’m interested!

Great, thanks, please test and let me know your feedback!

New version 16k is up - still emergency focus but also includes a bit of a pivot back to non-emergency use cases as well, such as video door bell and work from home conveniences, see example extensions 222328 and 222486.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.