Emergency (911) Support expansion - Legal requirements...


Folks, I wanted to make you aware of a ticket I opened with support a few months ago, in an attempt to get Grandstream working on a fix that will affect anyone trying to install these systems in certain states…

In September of last year, “Kari’s Law” (http://gohmert.house.gov/uploadedfiles/karis_law_final.pdf) went into effect in Texas. It’s primary purpose was to ensure anyone could simply dial “911” upon receiving dial tone (even if the system itself required an “outside” access code, such as “9”). Additional provisions included requirements for OSN (on-site notification) as well as location accuracy.

Several states already have laws on the books (http://www.911etc.com/legislation) regarding the handling and notification of 911 on a PBX (or MultiLine Telephone System = MLTS, as they call it).

All of them require access to both 911 as well as 911 (eg: 9-911). Some states also require on-site notification so when Emergency Services arrives, the lobby or security desk can route them to the right location. Some states have additional requirements regarding maximum square footage per ELIN (Emergency Location Information Number), requiring a dedicated DID (essentially) per floor, wing, area, etc. Some even have requirements that the person be able to be called back directly in case the call is disconnected.

For states that don’t currently have active laws, several are slated to within the next 18 months. This means, there could be as many as 30 states where Grandstream systems are no longer eligible to be installed for new installations - big bummer!!!

As it stands now, what we’ve had to do (and it only works with SIP trunks), is create a dedicated SIP trunk for each ELIN (with that number hard-coded on the trunk and checked as Always Use Trunk CLID). We also set it to record, so there’s a record of the emergency call. We then create dedicated outbound rules for each location, restricting access to it with an extension group that has members for each location. This works OK but it doesn’t accommodate if someone logs in their extension from another location (hot desking/hotelling), or the fact the system now supports multiple registrations. There is no provision for on-site notification at all, either (not even a work-around).

What I proposed to Support was the following:

Here’s how you’d do it:
Outbound route: Checkbox that it is an EMERGENCY ROUTE (this makes it eligible for notification)…

Network Location Map: Assign IP Scopes to “Locations” and assign emergency numbers to that location. Would also be good to assign regular outbound Caller ID by location (if not assigned, would use DOD table instead -
order of preference). Additional checkbox to RECORD EMERGENCY CALLS from this location so such calls are recorded. Lastly, a field to enter the inbound DID for this location, so if emergency services wants to call back, they can. For 1 hour after an emergency call is placed, that DID is mapped directly back to the station that made the emergency call. If multiple extensions call, the most recent extension is used for the call-back mapping. There would need to be an option to handle unassigned IP scopes (for phones on the public internet that shouldn’t be able to call 911), or to route the calls instead to an internal location.

Emergency Notification (by location - could select the extensions, or extension lists you want to be notified): When an emergency call is made from x location, an additional call is placed by the system to the notification extensions with Caller ID that shows EMERG>extension, name, location (derived from the network location map name). Would also be good to have a checkbox that says “Alert Answer allowed to Monitor” (would let the alert destination listen to the call, but not join in). Would also be good to be able to select if alert destinations continue ringing when one person answers, or if all parties need to answer. Alert calls should ignore forwarding and voicemail. Alerts would require BLF support, so a dedicated button can flash while an emergency call is going on - pressing the button displays the data of the emergency call and monitors the call (if monitoring was enabled).

What I’ve described is exactly how the Avaya implementation works, and you may have to do it in a phased approach (first the IP locations, DOD assignments, and inbound DID mapping, then later add the alerting). But with Asterisk as the back end, I know it’s all completely do-able.

FreePBX implementation is similar to this, but they assign the emergency numbers on a per-station basis (not based on where the phone is actually registered/calling from). Their implementation is bad in that regard, since the system can handle multiple registrations for a station (which could span multiple locations), and because if someone logs in from another location their emergency number is now wrong.

I can give you detailed screenshots from an Avaya system on how this is all set up, if the developers require this…

If you all see value in this, please communicate this not only to Grandstream support, but your Distributor as well, because this will become a big issue - it’s already a big issue, that just hasn’t bitten us yet…



The emergency calling (911) part of the UCM really does seem to be quite shy of anything reasonable even for a single location.
As a minimum it should be possible to force all 911 calls to route out a specific trunk, either a SIP trunk or analog trunk if available.

I agree that the rest of this become critical quite quickly or the market for the UCM will shrink quite dramatically.

Multiple locations need to be factored in too of course. This post is quite old and well articulated, it is suprising that there is not yet a resolution.


You can control which trunk any pattern of numbers go out through, including 911,by the use of your Outbound Rules. You can also use Filter by Source Caller ID to have different extensions use different trunks to for the same number.

I cuurnently use this do exactly that.


What is the current state of calling emergency numbers? Is Grandstream UCM capable of sending geolocation data for different locations nowadays?

Our voice provider uses https://datatracker.ietf.org/doc/html/rfc5491