Alternative solutions for new E911 rules in 2020

Thanks dicko!

Hi Luke,

Sangoma is doing final QA testing on our FreePBX 911 solution.
We are going to be pushing it to EDGE ASAP so you can have a look and test it yourself.
This is our top priority.

Nenad

1 Like

I restored some earlier unreleased ChanSpy() usage back into the newest ABC version v16d released on 2020-02-02. I think the new Tin Can Mode should satisfy your concerns about routing vs. answering, but there are technical shortcomings which I highlight in the included documentation. But basically, when in Tin Can Mode, the caller and remote end are now only moved into the conference after the remote end answers the call. Please see new Example #4 in the AEL file.

ABC continues to offer minimal Geolocation SIP header support per RFC6442. This may be compliant with some existing SIP providers and was present from before the OP.

The new version 16d adds support for dynamic call back DID allocation (see new Example #3 in the AEL file.)

I also significantly improved the documentation and re-worked the examples to provide 922 as test number for easier integration with existing systems.

That’s great and all. I won’t be using this or recommending this at all. It doesn’t comply with the laws.

same = n,AELSub(pngnpbx-abc-howdy-yall) ; Enter the conference. No more dial plan processing occurs for caller.

This proves my point. It fails to route the call to the PSAP but instead routes it into a local conference bridge. Fails to comply with that alone.

Also, why is all your dialplan syntax wrong?

1 Like

So my previous post was flagged as inappropriate?! Can someone please tell me how it was? Because I said I would not use this solution or recommend it due to it not complying with the new laws?! Outside of it hurting someone’s feelings it was not inappropriate.

I also pointed out that their solution had wrong dialplan syntax. So again, that was inappropriate?

1 Like

Tin Can Mode was added in ABC v16d, released yesterday, to specifically address some of the concerns regarding Dial() vs. ConfBridge() ie. routing vs. answering. Please see Example #4 included at the top of the ABC AEL file for this (degraded) mode. You might also think of this new mode as “Almost Always Be Conferencing”.

; Example #4:
; -----------
; Using "Tin Can" mode for Dial to remote instead of Originate.
; Please see "Tin Can Mode WARNING" near the top of this file.

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

exten = 922,1,NoOp()
 same = n,NoOp(placeholder)
 same = n,Log(VERBOSE,Always Be Conferencing - PenguinPBX.com)  ; Please copy and change as you wish!
 same = n,Set(ABCTO=933)                                        ; CHANGE ME! Remapping of the dial to another number (if any.)
 same = n,Set(ABCTRUNK=#YOUR-TRUNK#)                            ; CHANGE ME! Remapping of the dial to another number (if any.)
 same = n,Set(ABCPATH=PJSIP/${ABCTO}@${ABCTRUNK})               ; CHANGE ME! Endpoint section defined in your PJSIP configuration.
 same = n,Set(ABCCALLBACK=3035550000)                           ; CHANGE ME! Default call back number used if dynamic allocation fails.
 same = n,Set(ABCFRIEND=PJSIP/1113)                             ; CHANGE ME! The local PJSIP endpoint to bridge into the call.
 same = n,Set(ABCTYPENAME=abctest)                              ; CHANGE ME! Use abctest as the conf type name.
 same = n,Set(ABCRINGTIME=120)                                  ; MAYBE CHANGE ME! Rings remote end / path for 2 minutes.
 same = n,AELSub(pngnpbx-abc-tincan,${ABCTYPENAME})             ; Tin Can mode. Uses Dial instead of Originate to the remote.
 same = n,AELSub(pngnpbx-abc-path,1,${ABCRINGTIME},${ABCPATH})  ; Set the first (and only) call path to use on call to remote end.
 same = n,AELSub(pngnpbx-abc-remote,${ABCCALLBACK},static)      ; In Tin Can mode, this spawns Originate to a ChanSpy dummy not the remote end.
 same = n,AELSub(pngnpbx-abc-friend,1,${ABCFRIEND})             ; Bridge in the other attendee automatically.
 same = n,AELSub(pngnpbx-abc-howdy-yall)                        ; In Tin Can mode, this dials the remote and then enters the conference after they answer.

In contrast, Simple Mode continues to work the same as before, by immediately placing the caller into the conference.

I am updating the documentation to make this more clear in the next version. I will also try to update at least Example #1 to increase some verbosity eg. removing same keyword in favor of exten on every line. Thank you for the feedback.

What version of Asterisk did you try parsing it in?

I am testing ABC against Asterisk certified version 16.3-cert1, released in December, and both the CONF based and AEL based portions of the dial plan load fine for me.

Yes, that is how it works in Simple Mode. But in Tin Can Mode it routes the call using Dial() as you’d expect – there is no early answer of the caller – and only after the remote end answers does everybody get put into the ConfBridge().

I am still not sure what you mean. But I just released version 16e with improved documentation. Please let me know if you still see incorrect dialplan syntax eg. line number.

Besides a new mini-HOWTO for FreePBX users, here is the updated list of features:

FEATURES

========

~ Instant (Simple Mode) or delayed (Tin Can Mode) bridging for caller.

~ 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.

~ Optional automated playback of GPS co-ordinates to remote end upon answer.

~ Preliminary support for RFC6442 Geolocation headers with some SIP providers.

~ Saves first thirty seconds of call as voicemail (to email) (if configured.)

~ Optional full call recording of each participant leg of the conference.

~ Easy integration with existing ASTERISK and FreePBX(R) installations.

To accommodate Tom’s concerns, why not do it this way:

  1. Have the 911 call go straight out to the Trunk.
  2. Have a conference bridge that connects to the existing call via ChanSpy (or perhaps a notification call that gives the attendant the option to connect to the call via ChanSpy)?

I agree. That is basically what it does in Tin Can Mode in the latest version. The only difference is that the FreePBX “Trunks” need to be manually specified because ABC does not include any FreePBX concepts – it is pure Asterisk dial plan.

To accommodate my concerns the entire conference bridge portion of this would have to be removed. Because, as I keep saying this, it does not comply. Not only must the user not have to dial a prefix, dialing 9-1-1 must directly route to a PSAP. So again, dialing 911 and ending up in a local conference bridge on the PBX is not direct routing to a PSAP.

So everyone can sit here and come up with ways to make this conference bridge base solution comply but the conference bridge itself is the component that is making it not comply. Again, you guys want to roll this out that’s fine with me. Go for it. I’m going to do my best to avoid the $10,000 initial fine, the $500/day out of compliance fine and avoid having judgement’s against me the best I can.

Look these new laws are now in effect for the most part. On top of this thanks to the TRACED Act (which was made law in late Dec. 2019) the FTC took out five VoIP providers in the US for violation of the TRACED Act before the end of Jan 2020. So you guys want to take those chances when it seems like they will be cracking down on these new laws have at it.

For us these laws are completely impractical.

We are a relatively unique environment with 200 IP phones and 1000 analog ones, which are either in old residential buildings or somewhere in basements, cottages, etc, distributed over several sites within a relatively large area.

Am I supposed to get a unique DID and E911 for all of the analog phones too? (All calls go out our VoIP trunks)
Well that would be around $1000 a month extra for no gain.
Our users are also trained to never dial 911 on emergencies but an internal number that routes to 24/7 security staff.

Besides, most rooms and buildings, even if we provide unique address and exact location info, e.g. like garden house 1st floor, would never be found by police and medics without help of local security to show them where they need to go.

Do you think that below solution would comply with the new law?:

Somebody dials 911. It goes to the PSAP and at the same time a script is being executed that starts an automatic call which notifies our 24/7 security personnel from where and from which phone the 911 call originated.
The calling number shown to the PSAP, if called back, will reach our security people.

How does that sound?

While many of us have read the legislation, it’s a bit much to expect strangers over the internet to interpret for you.

IANAL :cowboy_hat_face:

That is exactly what Already Be Conferencing in Tin Can Mode can do! And much more!!

It really all depends. First, if you’re selling a residential or any type of POTS style (regular service) you already are supplying a DID and a 911 location (you should be at least). Residential housing requires 1 DID/Location for the entire house. A single story business building with up to 7K SQ FT can most likely get away 1 DID/Location for them.

So are all these lines using one DID to access them? They all present the same DID for CallerID when they make outbound calls? Or are these treated as individual lines?

As long as their is a dispatchable location to go with that, it’s fine. The laws do prefer that the callback go to the caller as much as possible but it can go to the emergency contact. The contact needs to be able to be onsite for EMS so if they are off-site they must always be able to go to the site when required.

1 Like

I previously provided a link in this thread to how some Skype Business implementations can initiate conference calls in emergencies. Please also consider taking a look at one of the the pertinent Federal Register documents from December 2019:

https://www.federalregister.gov/documents/2019/12/05/2019-20137/implementing-karis-law-and-ray-baums-act-inquiry-concerning-911-access-routing-and-location-in

b. Notification Timing

  1. Kari’s Law is silent on when the notification must be provided. The Commission proposed to
    require that MLTS covered by Kari’s Law be configured so that
    notification is contemporaneous with the 911 call and does not delay the placement of the call
    to 911. Most commenters that address this issue support the Commission’s proposal.

  2. We adopt the timing requirement as proposed but clarify that initiation of the notification must be
    contemporaneous with the call to 911. As RedSky points out, notification can occur in many
    forms, including SMS text messages, email, screen display, and conference calls, and the
    delivery of text messages and email is not within the control of the MLTS provider or the
    MLTS user. Accordingly, RedSky asks the Commission to clarify that initiation of the
    notification must be contemporaneous with connection of the emergency caller to the PSAP.
    We concur. The record shows the importance of timely notification. According to NENA,
    “[n]otification contemporaneous with the 9-1-1 call has significantly greater value to all parties
    than after-the-fact notification, and the majority of a notification’s benefits to response are lost
    if the notification is not conveyed in real-time.”

ABC supports dynamic outbound DID selection from a pre-defined pool in your dial plan, which will both be used for caller ID number and temporarily as a route back to the phone (PJSIP only at this moment on the call back path though - and it is a Dial back not yet a ConfBridge option.) See Example #3 in version 16e.

That is the notifications and saying that when the 911 calls happens the notification must happen too and not impede with the call. The notifications cannot be 20 minutes later saying “Oh yeah, this happened 20 minutes ago”.

So yes, you can conference the contacts together being notified but you cannot impede the call being routed directly to the PSAP when dialing 911. Your solution dumps the caller in a local conference bridge which does not constitute a direct routing to the PSAP.

I am removing the earlier shouting on this, but your assessment of the current ABC v16e behaviour is not accurate. In Tin Can Mode, which was introduced ~48 hours after the OP, the caller is not dumped into a local conference bridge; instead, they are “directly” routed to the remote end eg. PSAP. It is only after the remote end answers that both the caller and the remote end are upgraded from the Dial() application into the ConfBridge() application, by way of the ‘G’ option to Dial().

We have buildings where residents live, sometimes it’s a hotel like building with rooms, others are houses with several families in there, some are offices, somes storage places or barns.
Many of those buildings do not have an individual street address. They have copper wires going to them for phone but it’s all our internal wiring that we have built ourselves.

These analog phones are all internal within our PBX numbering range, none of them is directly reachable via a DID and yes, they do present the same DID when making outbound calls.

OK you sound like you qualify as a Interconnected VoIP Provider or at least you have situation where I’m going to tell you the same thing I told the OP, get a legal consult. I don’t mind offering up some insight here but as @lgaetz said, some of us have spent the time (a lot) going over this law and even (in my case) shelled out cash to get advice/consults for legal compliance.

You should be doing the same thing.

2 Likes