911 calling from a VICIdial agent desk: what the dialer does not handle

The fast answer: VICIdial has no 911 feature to rely on

Fast answer: VICIdial has no E911 (Enhanced 911) feature, no dispatchable-location capability, and no special handling anywhere in its schema, installer, or documentation for a dialed 911 call. A search of the entire corpus for e911 and dispatchable returns nothing. If an agent dials 911 from a VICIdial desk, it leaves exactly like any other outbound call: through the dialplan, out whichever carrier that campaign's dial prefix selects, presenting whatever caller ID that campaign is configured to present. Nothing in the software tells a carrier where the agent is sitting, and nothing notifies anyone on site that 911 was dialed. That responsibility sits entirely with the operator running the system, not with VICIdial.

New to agent, campaign, carrier, trunk, channel, or DID? “VICIdial terminology for complete beginners: users, phones, campaigns and leads” defines each of those five concepts — and none of them knows or cares what number a caller is trying to reach, including 911.

The rest of this article covers three things in order: exactly what a corpus-wide search for emergency-calling handling in VICIdial actually turned up, where a dialed 911 call technically goes once it leaves the dialplan, and the two deliberate choices an operator has for handling it, including why remote and hybrid agents make the second choice harder than it looks. A closing section names the current United States rules — Kari's Law and Section 506 of RAY BAUM'S Act — that most workplaces asking this question are actually trying to satisfy.

What a full search of the VICIdial corpus for 911 handling actually found

Nothing named e911 or dispatchable exists anywhere in VICIdial's database schema, its installer, or the upstream project documentation. That absence was checked directly, not assumed: every table, every column, every installer stage, and every documented feature were searched by name, and the search came back empty every time.

Every literal run of the digits 911 that did turn up in the wider corpus was a coincidence, not a feature. Checksums are the most common source: a script's own checksum can easily contain the digit run 911 somewhere in the middle of an otherwise unrelated hex string, purely by chance, the same way a symbol inventory line number or a UI asset's file size can. None of them are emergency-calling logic, and each one was traced back to its actual source before being ruled out; a specific checksum value is not repeated here because it was not independently re-verified against this site's own ViciBox 12 lab with sha256sum.

The only genuinely emergency-labeled features anywhere in the product are operational recovery actions with nothing to do with placing a call: an Emergency VDAC Jam Clear function on the Campaign Detail screen, and an emergency agent logout that hangs up an agent's session calls and forces them off the system. Both exist to help a supervisor recover a stuck dialer or a hung session. Neither one has any connection to what happens when someone types 911 into a dial pad.

grep -rIn -w -e 'e911' -e 'dispatchable' /etc/asterisk /usr/share/astguiclient /srv/www/htdocs 2>/dev/nullprintf 'Review every match above in full; do not assume a hit is emergency-calling logic without reading it.\n'

Where a dialed 911 call actually goes

A dialed 911 call gets no special treatment inside VICIdial's own machinery. Manual and automatic dialing both work the same way for any number: a command lands in the vicidial_manager table, an Asterisk Manager Interface Originate action follows it, and the call travels through a Local channel into the shared vicidial-auto-external context before Dial() hands it to whichever carrier that campaign is configured to use — the exact mechanism covered in full in “How the Asterisk dialplan works in VICIdial: extensions.conf, contexts and Local channels”. There is no branch anywhere in that path that recognizes 911 as different from any other three digits.

Two campaign-level settings decide what that carrier and the far end actually see, and neither one is aware of where the agent is physically sitting. campaign_cid is the outbound caller ID number the campaign presents on every call it places; dial_prefix is whatever digits get glued onto the front of a dialed number before it reaches the carrier. Both live on the campaign row, not on the agent, the phone, or the call itself, and setting up the carrier that ultimately receives that dial string is exactly the process walked through in “Connect your first SIP carrier so calls can leave the server”.

The phones table tells the same story from the other direction: it defines an extension, a dialplan_number, a phone_ip, a server_ip, an ext_context, and a local_gmt timezone offset, among many other fields, and none of them is an address, a floor, a room, or any other physical location. A VICIdial endpoint record simply has nowhere to put a dispatchable location even if an operator wanted to enter one by hand.

mysql --defaults-extra-file=/etc/vicidial-readonly.cnf --execute="SELECT campaign_id, campaign_name, campaign_cid, dial_prefix FROM vicidial_campaigns WHERE campaign_id = '<CAMPAIGN_ID>';" mysql --defaults-extra-file=/etc/vicidial-readonly.cnf --execute="SHOW COLUMNS FROM phones LIKE '%address%'; SHOW COLUMNS FROM phones LIKE '%location%';"

Two deliberate choices, and the dangerous non-choice

Given that nothing in VICIdial decides this for you, an operator running softphones, WebRTC agents, or any other multi-line telephone system for staff has exactly two responsible choices, and one irresponsible default.

The first choice is to block 911 at the dialplan and give every agent a different, documented way to reach emergency services — a labeled desk phone on a separate line, a personal mobile phone, a building intercom tied to a receptionist or security desk — and to make sure every agent, including anyone working remotely, knows that alternative before their first shift, not after an emergency.

The second choice is to route 911 deliberately, through a carrier that explicitly supports emergency calling and can accept a registered physical location for every endpoint it serves, then to actually register the correct address, and floor or room where that level of detail matters, for each station or softphone, and to keep that registration current as people and equipment move.

The dangerous option is neither of these. It is leaving 911 to travel through whatever carrier and caller ID a campaign happens to be configured with on a given day, decided by default rather than by anyone, and discovered — if it is ever discovered at all — during an actual emergency.

Choice 1 - Block, and document an alternative  - Block 911 at the dialplan so it cannot leave through a normal campaign trunk.  - Post a documented, different way to reach emergency services at every desk.  - Confirm every agent, including remote agents, knows the alternative before their first shift. Choice 2 - Route deliberately, with a registered location  - Choose a carrier that explicitly supports emergency calling.  - Register the correct address, and floor or room where it matters, for every endpoint.  - Re-register location the moment a station, softphone, or remote agent moves. The dangerous option is neither choice: letting 911 travel through whatever carrier and caller ID a campaign happens to have configured, decided by nobody in particular.

Remote and hybrid agents make dispatchable location harder, not easier

A softphone or a WebRTC agent registers from wherever it happens to be plugged in or logged in that day, and a carrier that accepts a registered location for an endpoint can only know the location it was actually given at registration time, not where the person using it is currently sitting.

An agent working from a home office today and a different address next month, or a hybrid worker alternating between an office desk and a laptop on a kitchen table, changes the true physical location far more often than most operators update anything in a carrier's records. A location entered once, correctly, at initial setup and never revisited afterward is not a dispatchable location by the time it matters; it is a stale one.

This is exactly why the two choices above call for treating a moved agent, a reissued laptop, or a new WebRTC station as its own event: either confirm the alternative emergency-calling route is still known and available at the new location, or re-register the correct address, and room or floor where that level of detail applies, with the carrier before that station takes its next call.

The regulatory backdrop: Kari's Law and RAY BAUM'S Act (United States only)

The choices above are exactly what two United States federal rules require a multi-line telephone system, an MLTS, the general regulatory term for a system like VICIdial serving more than one phone or station, to get right. This section names those rules; every attempt to read them from a primary source during this research was blocked, so treat what follows as consistently reported by secondary sources, and verify it yourself at the authority named at the end of this section before relying on it.

Kari's Law requires that an MLTS let a user dial 911 directly, with no prefix digit required first, and that it notify someone on site when a 911 call is placed. It applies to an MLTS manufactured, imported, sold, leased, or installed after February 16, 2020; systems in place before that date are not automatically covered.

Section 506 of RAY BAUM'S Act adds a second requirement: a 911 call has to carry a dispatchable location with it, the caller's street address plus enough additional detail, such as a floor or room number, for a PSAP, a Public Safety Answering Point, the facility that answers a 911 call and dispatches help, to find the caller quickly without needing to ask. Reported compliance dates are January 6, 2021, for fixed MLTS devices, and January 6, 2022, for non-fixed on-premises and off-premises devices, such as a softphone or a WebRTC station that can move.

None of this is legal advice, and none of it is specific to VICIdial: it is a general federal telecommunications requirement that applies based on where your staff are physically located, in this case the United States, regardless of which dialer or PBX software sits underneath their phones. Other countries have entirely different emergency-calling and multi-line telephone system rules, and this article does not attempt to cover them. Confirm current obligations, and how they apply to your specific configuration, with qualified counsel, and check the authority below yourself rather than relying on a summary.

• Kari's Law: direct 911 dialing, no prefix, plus on-site notification when 911 is dialed.
• RAY BAUM'S Act Section 506: a dispatchable location, address plus floor or room detail, travels with the call.
• Reported compliance dates: fixed MLTS by January 6, 2021; non-fixed on-premises and off-premises devices by January 6, 2022.
• This is a United States requirement; verify your own obligations at https://www.fcc.gov/mlts-911-requirements.

Verify with your carrier, never with a live call

The only sure way to know what a dialed 911 call currently does on your system is to read the dialplan and confirm the answer with your carrier, never to place a live call to 911 and see what happens.

Start by reading whatever your outbound context actually contains for a 911 pattern; the read-only inspection command below matches the same style used to confirm any other route in the dialplan. If the context blocks 911 entirely, or hands it to a carrier your operator has verified handles emergency calling and location correctly, you have your answer without ever touching a live emergency line. If it simply reaches the same context as every other number with no thought given to it either way, you have found the dangerous non-choice described earlier in this article.

Whichever way it turns out, follow up with your carrier directly, in writing, and ask exactly two questions: does this trunk carry emergency calls at all, and if so, what location does it report for each of our endpoints today. Use whatever test number your carrier's own compliance team provides for verification; do not use 911 itself for that purpose under any circumstance.

asterisk -rx 'dialplan show 911@default'printf 'No matching extension means 911 currently falls through to whatever generic pattern every other number matches in your default context.\n'