> For the complete documentation index, see [llms.txt](https://prosbcdocs.telcobridges.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://prosbcdocs.telcobridges.com/use-cases/applications/local-site-survivability.md).

# Local Site Survivability

Keep local extensions calling each other when a hosted PBX or cloud softswitch becomes unreachable. ProSBC answers already-registered phones from its own contact cache until the softswitch returns.

### Local Site Survivability

Phones and softphones register with a softswitch so they can be reached and can place calls. That softswitch is often not something the customer controls: it may sit at a hosted PBX provider, a cloud communications platform, or a carrier core, reachable only over a link the customer does not own either.

When that softswitch becomes unreachable, what users actually experience is not "a link went down" — registered phones lose their registration and can no longer call each other, even for a call between two desks in the same office, despite nothing on the premises having failed.

Local Site Survivability keeps those already-registered endpoints working. ProSBC recognizes the outage on its own, answers known phones from the registration record it already maintains, and hands control back to the softswitch as soon as it is reachable again — with no manual failover and no second system to maintain on site.

{% hint style="info" %}
Local Site Survivability is a different layer of protection than **SBC redundancy**: redundancy protects against the SBC itself failing, while Local Site Survivability protects against losing the softswitch connection while the SBC keeps running.
{% endhint %}

Throughout this page, *registrar* means the registrar role specifically, because that is the role ProSBC substitutes for. In a typical deployment that role belongs to a softswitch that also handles call routing.

### Typical Local Site Survivability Sample

<figure><img src="https://3811773442-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiK3TemJSDhHz3xNMOvvk%2Fuploads%2FQZf7iKbNDAd1D16TmltA%2FSIP_Registration.png?alt=media&amp;token=532795dd-56b2-4835-9365-7dae4d96d9b5" alt=""><figcaption></figcaption></figure>

### Key Capabilities

* **Local calls keep running** — a call between two locally known users is not dropped when the outage happens.
* **Known users can still call each other** — registered users keep placing and receiving calls between themselves during the outage.
* **Fully automatic** — ProSBC detects both the outage and the recovery on its own; no operator action, no manual failover.
* **One setting to turn on** — a single parameter on the SIP registration domain, with no separate system to maintain.

### How It Works

ProSBC keeps a local copy of every contact registered through a SIP registration domain, whether or not Local Site Survivability is enabled, and it tracks the registrar's reachability continuously. Nothing has to be built when an outage starts.

Local Site Survivability changes what ProSBC does with that record once the registrar stops answering:

| Event during the outage                                                  | Behavior with Local Site Survivability        |
| ------------------------------------------------------------------------ | --------------------------------------------- |
| Refresh from an already-registered contact                               | Answered locally with `200 OK`, not forwarded |
| Call between two locally registered users                                | Connected normally                            |
| Call in progress when the outage begins                                  | Continues normally until it ends              |
| REGISTER from an unknown user, or a contact whose listening port changed | Rejected with `480 Temporarily Unavailable`   |
| Unregister from a known contact                                          | Honored locally, cache entry removed          |
| Call that needs the softswitch (off-site number, softswitch features)    | Not available until the softswitch returns    |

#### Registration caching and throttling

The local contact copy is also what makes registration throttling possible. **Maximum Contact Expiration** caps the `Expires` value granted to the user agent, **Minimum Registrar Expiration** sets the floor on the `Expires` value asked of the registrar, and the two are configured independently — so endpoints can refresh far more often than the registrar ever sees.

User agents do not wait for the grant to run out before refreshing; most refresh well ahead of it, commonly at about half. ProSBC does not wait either: it re-registers toward the registrar once 40% of the `Expires` it was granted has elapsed. With the recommended values — Maximum Contact Expiration at 60 seconds and Minimum Registrar Expiration at 1 hour — the phone refreshes roughly every 30 seconds while the registrar sees one registration roughly every 24 minutes:

```
      Phone                    ProSBC                  Registrar
        |                         |                         |
 00:00  |==== REGISTER ==========>|==== REGISTER ==========>|
        |<========= 200 OK =======|<========= 200 OK =======|
        |     Expires: 60 s       |    Expires: 3600 s      |
        |                         |                         |
 00:30  |---- REGISTER ---------->|                         |  refresh at half the
        |<--------- 200 OK -------|                         |  granted 60 s
 01:00  |---- REGISTER ---------->|                         |
        |<--------- 200 OK -------|                         |  answered from cache
 01:30  |---- REGISTER ---------->|                         |  (not forwarded)
        |<--------- 200 OK -------|                         |
        |             :           |             :           |
        |    (repeats every 30 s) |                         |
        |             :           |             :           |
 24:00  |==== REGISTER ==========>|==== REGISTER ==========>|  40% of the granted
        |<========= 200 OK =======|<========= 200 OK =======|  3600 s has elapsed,
        |                         |                         |  so this one goes on
```

The forward rides a phone refresh. ProSBC does not re-register on a timer of its own, so the registrar side is renewed by whichever refresh happens to arrive once that 40% threshold has passed.

#### The outage lifecycle

From normal forwarding through an outage and back:

```
     Phones                             ProSBC                          Registrar
        |                                  |                                  |
        |                                  |------------ OPTIONS ------------>|
        |                                  |<----------- 200 OK --------------|
        |                                  |                                  |
 User A |-- REGISTER (UserA@example.com)-->|-- REGISTER (UserA@example.com)-->|
        |<--------- 200 OK ----------------|<--------- 200 OK ----------------|
 User B |-- REGISTER (UserB@example.com)-->|-- REGISTER (UserB@example.com)-->|
        |<--------- 200 OK ----------------|<--------- 200 OK ----------------|
        |                                  |                                  |
        |                                  |------------ OPTIONS ------------>|  no response
        |                                  |             :                    |  registrar marked
        |                                  |------------ OPTIONS ------------>|  down, domain
        |                                  |                                  |  enters Survivability
        |                                  |                                  |
 User A |-- REGISTER (UserA@example.com)-->|                                  |
        |<--------- 200 OK ----------------|                                  |  answered from cache,
 User B |-- REGISTER (UserB@example.com)-->|                                  |  not forwarded
        |<--------- 200 OK ----------------|                                  |
 User C |-- REGISTER (UserC@example.com)-->|                                  |
        |<------- 480 Unavailable ---------|                                  |  not in the cache,
        |                                  |                                  |  so rejected
        |                                  |                                  |
        |                                  |------------ OPTIONS ------------>|
        |                                  |<----------- 200 OK --------------|  registrar back up,
        |                                  |                                  |  domain returns to Up
        |                                  |                                  |
 User A |-- REGISTER (UserA@example.com)-->|-- REGISTER (UserA@example.com)-->|  on their own next
        |<--------- 200 OK ----------------|<--------- 200 OK ----------------|  refresh, not pushed
 User B |-- REGISTER (UserB@example.com)-->|-- REGISTER (UserB@example.com)-->|  by ProSBC
        |<--------- 200 OK ----------------|<--------- 200 OK ----------------|
        |                                  |                                  |
```

The diagram shows OPTIONS doing the detecting, which is the clearest case. On a domain with steady refresh traffic the poll is suppressed and a stalled REGISTER detects the outage instead, as described under [Timing](#timing).

#### Outage detection

ProSBC considers a registrar down when it stops answering the requests sent to it, whether the request is a SIP OPTIONS poll or a REGISTER that ProSBC is forwarding.

A REGISTER answered with a 5xx by a reachable registrar is still a response, so it does not itself trigger survivability. A REGISTER that gets no response at all can contribute to the same down-detection timer a poll would.

#### While the registrar is unreachable

* A refresh from an already-cached contact is answered locally with `200 OK` and not forwarded.
* A REGISTER from an unknown user, a new registration dialog, or a contact whose listening port changed is rejected with `480 Temporarily Unavailable`.
* An unregister for a cached contact is honored locally and removes that cache entry.
* A REGISTER that is forwarded but goes unanswered does not evict the cached binding; the endpoint's normal retry still succeeds from cache.
* New calls placed between two locally cached contacts continue to work normally. A new call that needs the registrar's softswitch itself — a number outside the site, or a softswitch feature such as voicemail, conferencing or transfer — does not.

#### New calls during an outage

Caching a registration is necessary to reach a survived contact, but not sufficient: the call route still has to resolve its destination from the registered-user data, which is a routing decision rather than something Local Site Survivability does on its own.

In a static-route configuration, set the call route's destination NAP to **(By registered or DNS user)** and the shipped base routing builds one route per cached contact. No custom script is needed. This is normally already in place, because it is the same setting that makes registered-user calling work while the registrar is up.

#### Recovery

Once the registrar answers again, normal forwarding resumes automatically.

{% hint style="info" %}
ProSBC does not push or resync cached registrations to the registrar on recovery. The registrar only learns about a contact again when that endpoint's own next natural REGISTER refresh reaches it, so until each contact's refresh interval elapses, the registrar's view of who is registered can lag behind ProSBC's cache.
{% endhint %}

### Timing

#### Detecting the outage

**Proxy Polling Interval** on the registrar's NAP (default: 1 minute) is how often ProSBC polls the registrar with SIP OPTIONS while otherwise idle. It is configurable over a wide range, so tune it to the deployment rather than relying on a fixed detection time. See [SIP NAP Polling](/configuration-details/configuration-by-web-portal-category/network-access-points-nap/sip-nap-polling.md).

The polling interval is not the whole story on a busy domain. ProSBC only sends a poll when it has not recently sent the registrar a request of any kind, so a domain with frequent REGISTER forwarding suppresses the poll and detection is then driven by whichever request stalls first — in practice a REGISTER. In that case detection follows the endpoints' refresh cadence, not the polling interval.

#### Repopulating the registrar after recovery

Because nothing resyncs on recovery, the registrar only learns about a surviving contact again when that endpoint's own next REGISTER refresh is forwarded. The gap between recovery and a correct registrar view is one endpoint refresh interval. Since user agents typically refresh at around half the granted `Expires` value, that interval is a fraction of what is configured — but the user-side registration time is still the parameter that sets it.

This is why the configuration steps shorten the register values from their 1-hour defaults. **Maximum Contact Expiration** caps the `Expires` value granted to the user agent, so it bounds how often the phones refresh and therefore decides how quickly the recovered registrar is repopulated. At 60 seconds, surviving users register anew within seconds of the registrar coming back instead of waiting out a long registration.

The cost of a short value falls on REGISTER traffic between the phones and ProSBC, not between ProSBC and the registrar. Registration throttling forwards a refresh only when the contact is new, has changed, is not yet active, or has passed 40% of the `Expires` the registrar granted, so the registrar side stays paced by **Minimum Registrar Expiration** rather than by the phones.

{% hint style="info" %}
That throttling is only active while **Minimum Contact Expiration** is lower than **Minimum Registrar Expiration**. If it is not, every refresh is forwarded, and shortening the user-side value does reach the registrar. The recommended values — 30 seconds against 1 hour — satisfy this.
{% endhint %}

On a site with many cached endpoints, also review the domain's **Maximum Pending Register Forward** and **Maximum Simultaneous Register Forward** settings: they govern how fast the backlog of REGISTER refreshes reaches the registrar after it comes back up, so reconnection is not needlessly slow.

### Requirements

* A **license** including the *Local Site Survivability* feature. Without it the configuration still saves, but the effective mode is forced to Disabled and the web portal raises a non-blocking warning.
* **Poll Remote Proxy** enabled on the registrar's NAP. This is mandatory — the feature relies on the registrar's up/down state, which is only maintained while the NAP polls the remote proxy.
* The matching call route's destination NAP set to **(By registered or DNS user)**, so calls between survived contacts can still be routed.

Saving a domain with Local Site Survivability enabled while its registrar NAP(s) do not have Poll Remote Proxy enabled fails with:

```
Sip registration domain update failed: Local survivability mode requires
'Poll Remote Proxy' to be enabled on registrar NAP(s)
```

### Configuration

See [Local Site Survivability Configuration Instruction](/configuration-details/configuration-by-use-case/local-site-survivability.md) for the configuration steps and troubleshooting.

### Routing scripts consideration

Routing scripts that resolve destinations themselves read the same registered-user data as the static routes: `params[:registered_user]` for the called party and `params[:calling_registered_user]` for the calling party, each exposing the contact's host, port and transport, the Contact URI, and which Routing Method is configured. See [Accessing Information about Registered Users](/configuration-details/configuration-by-web-portal-category/routing-scripts/development-guides-and-tutorials/accessing-information-about-registered-users.md).

That same data source is what Local Site Survivability populates from its cache when the registrar is unreachable, so a routing script already built to resolve destinations from `params[:registered_user]` per that documented pattern keeps working unchanged during an outage.

A script that resolves destinations some other way — by querying the registrar directly, for instance — will not complete a new call during the outage. Confirm which pattern a deployment's script actually uses.

### Limitations

* **No authentication in cached mode.** A previously registered contact is trusted without re-validating credentials.
* **No alias matching.** Matching is by registered Contact/AOR only — no extension numbers, DIDs, or alternate SIP usernames.
* **Cache is not persistent across a restart.** A restart while the registrar is still unreachable clears the cache; previously known users are rejected until the registrar recovers.
* **Not synchronized across an HA 1+1 pair.** Local Site Survivability runs independently on each host; the cache one host builds is not shared or replicated to the other. A failover to the standby host starts with an empty cache.
* **No resync on recovery.** ProSBC does not push cached registrations back to the registrar; the registrar's view catches up as each endpoint's own refresh is forwarded.
* **Down-detection is not limited to OPTIONS polling.** A stalled forwarded REGISTER can drive it too.

### Related Use Cases

* [Hosted PBX](/use-cases/applications/hosted-pbx.md)
* [Remote Workers](/use-cases/applications/remote-workers.md)
* [SIP Trunking](/use-cases/applications/sip-trunking.md)

### References

* [ProSBC Datasheet](/appendices/appendix-b-product-datasheets.md)
* [SIP Registration](/appendices/appendix-a-glossary/glossary-sip/glossary-sip-registration.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://prosbcdocs.telcobridges.com/use-cases/applications/local-site-survivability.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.