Quick answer: E911 is the U.S. name for routing an emergency call with the caller's dispatchable address attached. On a CPaaS, the routing obligation sits with the carrier, while the address lifecycle (register it, validate it, record the provider confirmation, keep it current) is a tenant-owned workflow you either operate or do not. Every vendor, Devotel Orbit included, should state its outbound emergency-dialing posture in writing; Orbit's is block-and-disclaim, with the address kept as a regulatory record rather than a live emergency-calling guarantee. The buyer review that matters is the one that separates those two declarations.
Instant messaging, WhatsApp, RCS, email, video. A platform can carry all of them and still fail a healthcare, insurance, or logistics procurement review on the fifth channel, which is voice. Inside a voice review, the question most engineers skip and most legal teams ask first is the emergency-call question: what happens when someone at your customer's site dials 911, 112, 999, or 000 through this platform?
This post walks the four declarations an emergency-call answer actually contains and the three deployments where the honest answer is "not through this platform." Everything below is sourced to the public contract, the emergency-address reference and the per-number dashboard card the API backs.
1) What "carrier-grade emergency calling" actually means
Enhanced emergency calling attaches a dispatchable civic address to a call so the receiving PSAP routes responders to the right location instead of a billing record. The obligation that makes it "carrier-grade" is split between two parties, and the buyer question is which of them the vendor handles:
- Routing obligation sits on the carrier. In the U.S., the FCC's RToS and E911 obligations attach to the voice carrier of record for the number. A CPaaS that originates its own numbers handles that obligation directly, while a bring-your-own-carrier layer pushes it downstream to whichever carrier owns the DID. Either way, routing is a carrier property, not a customer configuration, and not a platform feature a tenant toggles on. Adopted rules in Kari's Law (direct-dial 911 without an access code) and RAY BAUM's Act (a dispatchable location per fixed and nomadic caller) define what "correct routing" means, and the carrier answers for both.
- Address obligation enters as a stored record. The dispatchable address that makes routing useful is a stored, validated confirmation against the carrier's MSAG (Master Street Address Guide) or an equivalent PSAP reference. The granular lifecycle (registered, valid, dispatchable) matters because a stored address with no provider confirmation behind it is a potential location, not a usable one.
The two rules interact in a predictable failure mode: the carrier accepts the 911 call from a phone at an unregistered or stale address, routes it to the local PSAP by region, and the responder has only the generic civic guess to work from. That failure belongs to the tenant side of the ledger, which is why the next section is the operational part of the review.
2) The tenant-side responsibility — a dispatchable address per number
E911 registration is per-number (a single number can only carry one address at a time), and the checklist a tenant operates is four steps, each visible as an API call and mirrored in the dashboard on each number's detail page:
- Register the civic address.
PUT /numbers/:id/emergency-addresswrites the caller name, street, city, region, postal code, and country (an ISO alpha-2 code; the shape is country-agnostic). An update replaces the prior address and resets the lifecycle, so any earlier validation or confirmation attached to the old address no longer applies. - Verify locally.
POST .../emergency-address/verifyruns a structural pre-check: required civic fields present, postal-code shape strict for the two NANP countries and length-only elsewhere. A clean result moves the address tovalid. This check is deliberately local-only; it never costs money or touches a provider address API, andvalidis not the end state. - Record the provider confirmation.
POST .../emergency-address/psap-confirmationingests the carrier or PSAP MSAG verdict that arrives out of band, withconfirmed: trueflipping the address todispatchableandconfirmed: falseflipping it toinvalidwith a required rejection reason.dispatchableis the only status that means a usable emergency location. - Re-verify after every edit. Any
PUTresets the lifecycle toregistered, so the confirm step has to be rerun whenever the address moves. A tenant that registers an address once and treats registration as permanent has built a stale-address pipeline, and a stale address routes to the wrong PSAP in the same way no address does.
A test-call allowance sits quietly inside this loop: after an address reaches dispatchable, calling back out to verify the dial path works is usually permitted only during a scheduled test window the PSAP coordinates. The tenant checklist ends when the carrier's emergency-call table actually shows the address attached, which is also the only way the configuration exists in any meaningful sense.
On Orbit, the lifecycle is per-number and gated by organization ownership: a sibling subaccount sharing a tenant schema can neither read nor mutate another subaccount's dispatchable location, which keeps address records tenant-scoped by construction rather than by operator discipline.
3) How Devotel Orbit handles it — block-and-disclaim on the outbound path
Orbit's emergency-dialing posture is block-and-disclaim, and a reviewer should read that as a deliberate answer rather than a missing capability. Outbound emergency dialing (911, 112, 999, 000) is disabled at the platform level on the outbound voice path; what the address registration machinery does is keep the regulatory record, validate it structurally, and record the provider verdict. The posture is a documented, deliberate decision, and the per-number routes implement the four-step lifecycle above as the record-keeping surface that decision leaves open.
That posture is shared across the outbound voice surface, so it should be part of your integration contract, not discovered in an incident. The questions it eliminates are predictable: "can a softphone dial 911 from Orbit" has one answer, and the surface that remains is the address record the carrier still expects you to keep current. If your deployment needs a live outbound 911 path, the right carrier is the one that routes it, with Orbit's address record supplying the dispatchable-location bookkeeping underneath.
The same posture interacts with inbound from the other direction: a phone that calls into Orbit can be assigned to a zone or queue, while the obligation to route its own emergency call correctly still belongs to whichever carrier owns the DID. For deployments built on bring-your-own-carrier, that split is the difference between holding one contract and holding two.
4) When you CAN'T rely on VoIP 911 — three deployment patterns
The block-and-disclaim posture above is the platform answer, and it is also the answer for a class of deployments that no platform can rescue:
- Nomadic users. A softphone user who moves between a head-office desk, a home office, and a hotel room needs a dispatchable location that follows the device rather than the civic address registered on the number. Orbit's per-device dynamic-location routes under
/:id/emergency-address/locationtrack the device's current dispatchable location, which solves the record problem; the routing problem still belongs to the carrier, and a nomadic endpoint that never syncs its current location has a stale-address failure with extra paperwork. - International numbers. The U.S. E911 model is not the only emergency-calling model. The UK dials 999 through the operator-connected emergency service, the EU uses 112 with a member-state-level routing layer on top, Australia's 000 terminates through Telstra as the universal emergency provider, and each country's address-confirmation and PSAP-handoff rules differ enough that a single "emergency address" record is an input to local behavior rather than a portable guarantee. Orbit's address shape is country-neutral on purpose, but the downstream PSAP confirmation is still per-country.
- Microsoft Teams direct-routing edge cases. Teams Phone with direct routing terminates the call at an SBC that a tenant operates, and Orbit is not the last-hop carrier in that topology. Emergency-calling for those endpoints belongs to whatever the SBC hands to, which in some Teams Phone deployments is the carrier that operates the SBC and in others a downstream service provider. A buyer review that names Orbit as the emergency-calling answer for a direct-routing deployment has already routed the incident to the wrong party by assumption, before anyone dials anything.
For each of these, the honest deployment pattern is the same: keep the address record on the platform that owns the number, know which carrier answers for routing, and block what the platform cannot deliver so the gap is never exercised accidentally.
Frequently asked questions
Does registering an E911 address enable emergency dialing?
No. Registering records and validates the dispatchable location; outbound 911 on Orbit stays blocked at the platform level. Registration makes the address record usable for whichever carrier routes emergency calls from that number, but it is not a live-dialing guarantee, and you should not treat it as one.
Which status is the "real" one: valid or dispatchable?
dispatchable. The valid status is a structural pre-check that never calls a provider, while dispatchable is the provider confirmation against the MSAG that the carrier ingested. The verify step exists so fixable issues (an empty field, a postal-format mismatch) surface before the provider incurs a lookup, and the confirmation step is the verdict.
Does the address shape change by country?
The shape is country-neutral. Required civic fields (caller_name, street_line_1, city, region, postal_code) apply everywhere, country accepts any ISO alpha-2 code, and postal-code validation is strict for the two NANP countries and length-only elsewhere. Behavior by destination (how 999 routes in the UK versus how 112 routes in the EU versus how 000 routes in Australia) is a carrier and member-state matter rather than a stored-address matter.
Can one subaccount see another's dispatchable address?
No. The address endpoints are organization-scoped by construction; sibling subaccounts in the same tenant schema cannot read or mutate one another's emergency addresses. That boundary exists precisely because address records belong to a legal entity, and the boundary is enforced at the API level rather than exported to operator discipline.
Where can I test the lifecycle before registering real numbers?
Against a test number in the sandbox. Register an address, run /verify, then post a /psap-confirmation with confirmed: true and confirm the status moves to dispatchable. The same sequence runs for a rejected confirmation, and your runbook should carry both paths because a rejected verdict surfaces failure detail in the validation_issues field you would otherwise read in production.