Alternative solutions for new E911 rules in 2020

Also bear in mind that Asterisk is a B2BUA, hence there are no “directly routed calls”, just bridged calls from the injured party to hopefully the PSAP. ChanSpy effectively bridges into the A leg, the proposal here seems so bridge into the B leg, I don’t see much of a difference if that is ‘illegal’ then the law is indeed an ass…

Perhaps another one for the lawyers

1 Like

I agree. In Tin Can Mode, ABC will send that OG caller straight through.

More technically, just before the Dial() is executed in the dial plan, a stand-alone ChanSpy is started on the OG caller, via Originate; one leg of this ‘golem’ is anchored to a (new) ConfBridge and the other ‘half’ runs ChanSpy to barge-in on the OG caller. This allows any other friends who answer before the remote end answers to start talking with each other and the OG caller (since friends Always Be Conferencing.) The ChanSpy is reaped once the remote end answers, at which point, everybody joins into the ConfBridge (with the friends who are in there from the start.) The transition upon answer from Dial() → ConfBridge() is nearly transparent to the participants – there might be a little echo.

Again, IANAL, but besides the definition of “directly” – which is vitiated in most recent versions of ABC due to Tin Can Mode – the question of “automated dispatchable location” is another point of contention…

Fixed devices. The rules for fixed devices operating on MLTS, fixed telephony, VoIP, or TRS require provision of automated dispatchable location with each 911 call, which means that the location information is generated automatically, without any action by the 911 caller when placing the call.

With ABC, you can configured the “announce” option, like so (from Example #2):

AELSub(pngnpbx-abc-init,abctest,record,3600,,announce,)

…that will set the internal ABC conf type name to abctest, save WAVs of each call leg of each participant into separate files, limit to one hour, and automatically announce GPS TTS to the remote end as soon as they answer. Actually it will play back to the entire ConfBridge when the remote end answers. (To shut up the bot, press #; to hear the GPS again, press * (SPLAT - YOU ARE HERE.))

Yes, you still need to configure GPS information, but there is a helpful IVR for end users to do this themselves included with ABC v16e, which takes about a minute to complete by dialing 123*222. I think it makes for more enjoyable user experience, even for over-worked IT Teams needing to roll this out sometime in the next year to potentially hundreds and thousands of phones:

  1. Hold cell phone in one hand with GPS app open to show current LAT/LON/ELV.
  2. With other hand, dial 123*222 on desk phone, follow prompts and enter the GPS co-ordinates using DTMF touch pad on the desk phone.
  3. Move on to the next phone in about 60-90 seconds. (Longer if you are training the user to self-manage in the future.)

I understand the GPS TTS idea is not perfect. But it could immediately work better with PSAPs in rural areas that do not yet accept E911 fully. My hope is that more SIP providers will start accepting RFC6442 Geolocation headers ASAP.

I did not say it was in any way any where in the OP. Please read it again. If your point was lack of discussion on the Asterisk forums makes sense somehow, I do not agree. For example, I think support for Geolocation SIP headers per RFC6442 is certainly within scope of discussion for many, many VoiP projects, including both FreePBX and Asterisk.

Also, I wanted to provide some updates on the most recently released version of Already Be Conferencing v16e, which I am pleased to report did since vitiate (love that word thanks @AdHominem) many of your other concerns expressed elsewhere in this post on the main thread.

Quite Simply – putting on my Tin Can here – there are new facts in the ABC configuration that I hope you’ll consider more fully, as work continues on changing and improving the work.

To help you this month, dear reader, and if properly configured, ABC can streamline notifications to people you choose whenever what you define as an emergency number is dialed – be it 911/922/933/999/etc. is called for testing, or whatever your locality uses if outside the USA, up to you you how you configure it in FreePBX/Asterisk – by way of the following notification methods, again, depending on your specific configuration needs:

  • Conference Calls. Between the caller; remote end eg. PSAP; and on-site staff such as Security, Mental Health, Front Desk, etc., allowing quicker rendering of local assistance - sometimes before remote end even answers the phone, let alone roll the truck. This somewhat novel approach might work well for rural areas and other locations where it is still legal (but it is not completely unheard of.)

  • Voicemail. First 30 seconds of call are recorded (configurable time limits coming in next version.)

  • Email. Via voicemail-to-email trigger/feature already inside Asterisk that you can manage from stock FreePBX GUI eg. for IT alerts. (Admittedly this exists in many other options.)

  • SMS. Via voicemail-to-email-to-mobile using carrier gateways like “vtext.com” and such. (This too exists elsewhere.)

To help this month and into the future, and if properly configured, ABC includes support for dispatchable location transmission (see also “Dynamic Location Routing” in your web searches) via GPS co-ordinates packed inside some of the basic Geolocation SIP headers defined in RFC6442 - which a small handful of SIP providers can already accept. (Others require street address and additional information - planning this for the next version - still testing providers.)

But ABC strives to go above and beyond the minimal requirements, in many ways.

The latest versions include options for in-band audio messages to announce the location via Text-To-Speech using existing stock Asterisk voice prompts, either automatically upon remote end answer or whenever a call participant presses the * key - SPLAT - YOU ARE HERE. This may be helpful for deaf callers; or others unable to speak; or mis-directed VoiP calls from children that end up in the “national PSAP” call centers; or those in rural areas that lack E911-enabled PSAPs, such as remote mining facilities with no street address to send the helicopter to.

Location information is stored in encrypted format while at rest on the PBX, but transmitted in the clear as-needed, such as the following scenarios:

  • GPS is sent during call flows you initialize according to your custom emergency dial plan rules in FreePBX/Asterisk (there’s test examples included with ABC and even a mini-HOWTO for FreePBX users to help get started in v16e.)

  • GPS is spoken when users are self-updating their GPS data internally, direct on a phone call from their soft/hard phones to the specialized IVR menus included in ABC.

  • During separate IT testing and verification processes, etc.

Also, to be very clear, I AM NOT A LAWYER, and the choices you make in customizing Already Be Conferencing configuration for your specific environment – from redirecting 922 calls to 933, to choosing between the ever-popular Tin Can Mode vs. more modern Simple Mode – are yours to keep with your free gift copy of Already Be Conferencing v16e, and do with as you like for your own purposes.

Current version is now v16g “Great Yurts Edition”. Compared to the previous v16f this one:

  • Adds Yurts, Palaces, Paladins and Trolls.
  • Adds subnet ID based caller ID selection.

OK, so I’m going to ask you a serious question because you are putting a lot of work into this. Here it goes:

You have taken into consideration that all MLTS systems must comply to the laws in the US. Sangoma just released their updates for this, all future FreePBX releases have it because they must. This goes for Thirdlane, ScopServ or any other MLTS vendor using Asterisk as their voice engine. So with that in mind, how will you make your solution something that people will want to use when they will already have a compliant solution baked in?

Glad you asked!

Honestly, I am still not satisfied with the current state of competing solutions to next week’s problem!

Also, the situation is incredibly fluid right now. It was only two days ago that Sangoma first “baked in” their solution into the FreePBX testing/EDGE branch, with stable release not planned until two days from now. Then of course there is the module signing fiasco threatening to disrupt some other solutions – perhaps as early as next week – which ABC completely avoids.

Disregarding current events, here’s some reasons you might want to consider ABC for your next project…

  1. ABC is licensed CC0 for maximum integration opportunity.
  2. ABC does not require FreePBX (but can be integrated with it, see Examples in file.)
  3. ABC works with stock Asterisk (although it is a little PJSIP heavy right now.)
  4. ABC is pure dial plan with no dependencies outside of the Asterisk Extension Language.

And I think the FEATURES list from near the top of the latest v16g file might help make the technical distinction more clear between ABC and competitors:

FEATURES

~ Multiple notification options: Conf Call, Page, Voicemail, Email, SMS.
~ Subnet ID based Caller ID options: currently IPv4 /24-/30 networks.
~ Dynamic temporary pool call back number ↔ caller ID mapping and routing.
~ DIY phone-based geolocation update support for changing GPS info via IVR.
~ Single press DTMF options to play back Dispatachable Location in-band.
~ Same DTMF options also display the DL info on the desk phone screen.
~ Optional automated playback of GPS co-ordinates to remote end upon answer.
~ Dynamic Location Routing via RFC 6442 Geolocation (with some SIP providers.)
~ Optional full call recording of each participant leg of the conference.
~ Instant (Simple Mode) or delayed (Tin Can Mode) bridging for caller.
~ Easy integration with existing ASTERISK and FreePBX(R) installations.
~ Examples included showing usage with FreePBX emergency caller ID numbers.
~ Coming Soon: Complete Ansibile-ized build on fresh Debian 10.

There is no competing solution for this. That is on the MLTS vendors to do, this isn’t a stand alone solution option. You get a Mitel PBX, Mitel has their solution in the PBX. You get a Panasonic PBX, they have the solution in their PBX. You get any software based PBX, it’s still an MLTS system so they have the solution in the PBX. So again, at this point you are “competing” against every MLTS vendor using Asterisk as their engine.

The only real competition is with the carriers that need to have solutions. Will they give 100 DID+Location to the customer or will they be able to use Dynamic Location Routing? THAT is going to depend on the carrier the PBX admin chooses.

Also, a follow up question. What is the support plan for your solution? Is there one?

I don’t understand. What was the Clearly IP module if not free market competition ? How does ABC not fit in to free market competition of solutions to these problems ?

I agree. And maybe include every MLTS vendor that needs to rip out their non-Asterisk based system before January 2021 dispatchable location requirements start kicking-in because their (previous) offering is not field-upgradeable to support the changes to existing systems per Ray Baum Act ?

ABC does both – it already offers some support for (new) DLR using GPS, as well as the (old) registered address “buy all the DIDs” approach. I agree it depends on the carrier what you can do.

Do you want to try out ABC and help do this ? :cowboy_hat_face:

The Clearly IP module ties into Clearly IP SIP Trunking and Clearly IPs Dynamic Routing solution. It’s a commercial solution that requires a specific commercial service.

So you’re saying Mitel,Avaya, Panasonic and all those need to rip out their PBXes? You’re confusing a vendor (maker) with an installer/admin.

Also Dispatchable Location refers to the record received by the PSAP when the call is made. Most modern non-software PBXes such as Mitel support an Outbound CallerID per station which because most of those work with PRIs and PRIs come with 100 DIDs means each station can have a DID. Each DID can have its own 911 Dispatchable Location record in the database. Problem solved, Dispatchable Location achieved.

Except you’re assuming GPS is being used. Have you actually looked at what carriers who provide this service are doing and how they expect certain formats? Because many want SIP headers that has data specific to their service.

No, I do not want to but you really need to have this figured out the way you’re pushing this. You’re going to leave people stuck and wondering how to get support for your solution.

Subtle point taken, but any vendors offering direct-from-the-factory full-blown-MLTS maintenance/lease/warranty/support agreements as part of their business model will probably be affected.

I posted snippets of the Federal Register from December earlier in this thread. Here is a pertinent portion regarding Panasonic’s comments:

  1. Panasonic states that the definition of a “person engaged in the business of installing an MLTS” should be limited to initial installation and configuration of the system or substantial improvement, “lest over-long potential liability risk the exit of skilled installers from the market.” We decline to limit the definition to initial installation and configuration of the system, as Panasonic requests. Panasonic presents no data to support its conclusion that this would lead to the exit of skilled installers from the market.[8]

I disagree, slightly. The DL refers to the information. Getting the DL to the PSAP automatically is separate from the DL itself. Again, from a couple of footnotes in the Federal Register:

  1. We agree with Avaya that service providers may use any technology that delivers dispatchable location, including any technology that complies with NENA i3 specifications.
  1. In other words, the dispatchable location information associated with a fixed MLTS device must be conveyed to the PSAP when a user places a 911 call, without further intervention by the user at the time it places the call. As noted below, an MLTS operator or manager may rely on an enterprise customer to acquire, maintain, and keep up-to-date the location information associated with a fixed MLTS device.

That sounds nice but may represent change for many PRI configurations.

For example, the ability to mask individual per-station DIDs on normal calls, such as putting the main company number out the trunk as the Caller ID number, and only revealing the individual per-station DIDs as the Caller ID numbers during emergency calls, might not be available on all MLTS platforms.

Yes :slight_smile: please send more!

Bummer :frowning:

1 Like

While all of this sounds very interesting, the one question I’d ask the OP is if he bounced the specifics of his implementation off of any FCC representatives and/or legal resources. It’s one thing to release a new feature module for something relatively ancillary, such as a new SMS package or something. But when it comes to complying with very specific FCC regulations that can result in legal exposure depending…that’s something I personally wouldn’t undertake and promote unless I had vetted it to the Nth degree with iron clad points of reference!

2 Likes

Then one should reasonably ask the same question of Sangoma, apparently their very recently released solution in fact does pretty well the same as @penguinpbx amended “Tin-can” solution of over a week ago , a) make the call to your chosen PSAP, b) bridge the call to other “interested parties”

So I will :wink:

Sangoma, can you let please let us know exactly what your legal department thinks of where and what legal liabilities are involved for us by relying on your solution ?

1 Like

No, it does not based on everything I’ve seen. Sangoma’s solution injects one line of dialplan code into the Outbound Route that calls an AGI script which initiates a call to the Page Group plays the announcements and then uses ChanSpy() on the caller’s channel while dialing out the trunk…

In my opinion, a bridge is a bridge, page groups are bridges as is chan_spy, all calls in Asterisk are bridged, if all participants are sharing media they are ultimately ‘bridged’ even if some are muted. it really is semantics as to what you call it and how the bridge is initiated and endpoints added to it.

We all concede that the originator must initiate a direct call to the PSAP (by means of a bridge, because that is all Asterisk can do), how the other ‘notifications’ are engendered then follows, @penguinpbx attempt seems to go much farther to use other methods out of band to the audio bridge.

Please describe the difference of the two end results and why the courts would prefer one over the other.

They don’t care if it is a software PBX that can do flips and twirls. It’s based on the common market denominator and that is hardware based. So it is simple, a station dials 911 those digits must map/route to a PSAP which is over the “trunk” to the PSTN in almost every case. It doesn’t matter the specific PBX method/terms that is what it must do. Then there should be notifications in some format.

So FreePBX already complied with the ability to make an Emergency Outbound Route, with being able to set Emergency CallerID per extension/station. The only thing FreePBX needed was the notifications part. That is what this covers and since that is the only thing grandfathered (notifications) they were pretty covered. Now their notification method does not impede the 911 call in anyway to the caller or the operator. It pages phones and allows them to Spy if answered.

The OPs way has 911 routed as an internal route to an internal conference bridge that then uses initiates numerous additional calls that conference everyone, including the operator, into a conference bridge. Therefore the caller is not routed to a PSAP they are routed to a conference bridge. That also means that if there is an actual issue with the trunk/PRI the caller will not get a busy signal, they will not be alerted the line is having problems, they are sitting in a conference bridge waiting for others to join them including 911 no ring back, no way to tell of call progression, just dead air. I doubt making the MoH on ringing until another joins the conference will work as if someone joins that isn’t the 911 operator the caller will not know that. At that point you are now trying to make it look like a call is happening when there isn’t one.

I guess we are reading different threads here. I saw a Tin-can suggestion to cover that , did you?

(Personally I like the concept of calling ‘the big red car’ from my Yurt with a tin-can)

1 Like

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