Emergency Callback Numbers & Why Every Extension Needs a Way Back

Dalibor Bradvic

Product Owner

Any business with more extensions than DIDs, which is most businesses, because provisioning a DID for every single seat is expensive and usually unnecessary, has this exposure sitting somewhere in their phone system today.

Give us the failure case first. What actually goes wrong without ECBN?

An extension without its own dedicated DID places an emergency call. The call goes out fine, that part usually works. The problem shows up afterward: the responder needs to call back, maybe because the call dropped, maybe to confirm the address, maybe because they need more information. And there’s no valid number to reach that extension on. In the worst version of this, that callback simply fails, at the exact moment it matters most.

Any business with more extensions than DIDs, which is most businesses, because provisioning a DID for every single seat is expensive and usually unnecessary, has this exposure sitting somewhere in their phone system today.

Why can’t a partner just solve this by giving every extension its own DID?

Cost, mostly, and it doesn’t actually scale. If you’ve got five hundred extensions and forty DIDs because most people share lines or use extensions for internal-only purposes, provisioning four hundred and sixty additional numbers just to cover an emergency-calling edge case is a bad trade.

You’d be paying, permanently, for capacity you need only in the rare moment someone dials 911. ECBN’s insight is that you don’t need every extension to own a number, you need every extension to be able to borrow one, on demand, for as long as it’s actually needed.

Walk us through what happens the moment someone places an emergency call.

PBXware checks three things in order. First, does this extension already have a regular DID? If so, that’s used, nothing else needs to happen.

Second, does it already have an active ECBN assignment, say, from a call it placed twenty minutes ago? If so, that same number is reused and its clock resets, so the callback path stays consistent rather than changing numbers between related events.

Third, if neither is true, PBXware pulls a free number from the pool and assigns it right then. Whichever path it takes, that number goes into the SIP Contact header, so it’s the number a responder’s callback actually reaches.

What was the design tension in getting that assignment logic right?

The tricky part isn’t the happy path, it’s the reuse case. If every emergency call from an extension grabbed a brand-new number from the pool, you’d burn through your pool fast, and worse, a responder trying to call back ten minutes after the original call might reach a number that’s already been reassigned to someone else.

Reusing an active assignment and refreshing its timer solves both problems at once, it conserves the pool, and it keeps the callback number stable for the window when a callback is actually likely.

How long does an assignment last, and who decides that?

It’s configurable, the Emergency Callback Number Assignment Duration setting, 24 hours by default. After that window, the number goes back into the pool for reuse.

The right number for a given partner depends on their emergency-call volume and pool size. A partner with a small pool and infrequent emergency calls can run a shorter duration and still be safe but a partner who wants more buffer against callback delays might extend it. It’s a dial worth actually setting rather than leaving on the default.

What does the compliance story actually look like when someone asks a partner to prove this works?

That’s what the DID → Emergency Callback page and the logging exist for. Every assignment, successful, failed, or a case where a regular DID was used instead, gets written to a dedicated ECBN log table, and the full history is downloadable straight from that page.

If a partner is in a procurement review or an audit and gets asked “how do you guarantee emergency callback reliability,” the answer isn’t a policy document, it’s an exportable log.

Smiling businesswoman handshake with businessman while standing in the office.

How does this connect back to Part 1 and the DNO story?

They’re really one story told from two directions. DNO makes sure a call leaving a partner’s network can be trusted, the Caller ID is real, not spoofed.

ECBN makes sure a call arriving at emergency services can always be reached back. Regulators and enterprise customers increasingly ask about both in the same breath, because they’re both about whether a voice provider’s origination can be trusted end to end.

A partner who can speak to both, with logs to back it up, is answering a much harder compliance question than one who’s only solved half of it.

What’s the practical advice for a partner sizing their ECBN pool for the first time?

Start from the number of DID-less extensions in the deployment, not the total extension count, that’s the population that actually needs the pool.

Then look at realistic concurrent emergency-call volume, which for most businesses is very low, and size the pool with headroom rather than exactly to that number, since the cost of an undersized pool is a failed emergency callback, which isn’t a corner you cut to save on a handful of extra DIDs.

ECBN support is available now in PBXware 8.1.0. For setup details, see DID → Emergency Callback in the PBXware admin GUI, or reach out to your Bicom Systems contact.