> 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/configuration-details/configuration-by-use-case/local-site-survivability.md).
# Local Site Survivability
Configuration steps to enable Local Site Survivability on a SIP Registration Domain.
For what the feature does, how it behaves during an outage, its timing and its limitations, see the [Local Site Survivability](/use-cases/applications/local-site-survivability.md) use case.
### Configuration steps
1. Follow the instructions for [Configuring a Hosted PBX](/configuration-details/configuration-by-use-case/configuring-a-hosted-pbx.md).
2. Make sure SIP polling is enabled: **Poll Remote Proxy** on the registrar's NAP. Saving the domain fails if it is not. See [SIP NAP Polling](/configuration-details/configuration-by-web-portal-category/network-access-points-nap/sip-nap-polling.md).
3. Set **SIP Domain → Forwarding Parameters → Local Site Survivability** to **Cached contacts only**.
4\. Change the default register values on the domain:
| Parameter | Set to |
| ---------------------------- | ---------------------------- |
| Default Contact Expiration | 60 seconds (default: 1 hour) |
| Minimum Contact Expiration | 30 seconds |
| Maximum Contact Expiration | 60 seconds (default: 1 hour) |
| Minimum Registrar Expiration | 1 hour |
Save and apply the configuration.
### Troubleshooting
#### Confirming the domain state
The SIP registration domain has a fourth state, **Survivability**, alongside Unknown / Up / Down. Check it in this order.
**1. Web portal.** Open the **Status** page and select the **Sip** tab. The tab shows a warning color when at least one domain is in survivability, with a *Domain survivability list* between the up and down lists. The tab turns red if any domain is down, which takes priority over the survivability warning color. Available from ProSBC 4.0.2.
**2. tbstatus.** The same state is available from the CLI:
```
tbstatus /sip_registration/domain/registrar
```
**3. Gateway log.** The domain state transition is the line to grep for. It appears at REG trace level 1, in the gateway log under `setup//apps/gateway/`:
```
TBLV1 REG : State changed (Up => Survivability)
TBLV1 REG : State changed (Survivability => Up)
```
The pair confirms that recovery is automatic — nothing was configured or touched between them.
A `User request timeout` line shows a stalled forwarded REGISTER doing the down-detection instead of an OPTIONS poll, which is how the situation is recognized in the field.
#### Viewing the current registered users
The cached contacts are what the domain serves from during an outage, so the registered-user list is the second thing to check on a ticket: a user missing from it will be rejected with `480 Temporarily Unavailable` while the registrar is down.
```
tbstatus /sip_registration/domain/user
```
Routing scripts read the same data through `params[:registered_user]` and `params[:calling_registered_user]`. 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) for the fields each contact exposes.
#### Confirming the polling prerequisite is running
`tbstatus /nap` confirms that polling is not merely configured but actually going out:
```
- availability_percent 100
- availability_detection_struct
|- poll_remote_proxy Yes
|- is_available Yes
|- time_since_polling 51s
```
`poll_remote_proxy` confirms the setting and `time_since_polling` confirms polls are being sent. `tbstatus /system/naps` gives the same answer as an available and unavailable NAP list.
### Related pages
* [Local Site Survivability (use case)](/use-cases/applications/local-site-survivability.md)
* [Configuring a Hosted PBX](/configuration-details/configuration-by-use-case/configuring-a-hosted-pbx.md)
* [SIP registration forwarding](/configuration-details/configuration-by-use-case/sip-registration-forwarding.md)
* [Creating a SIP Domain](/configuration-details/configuration-by-use-case/sip-registration-forwarding/creating-a-sip-domain.md)
* [SIP NAP Polling](/configuration-details/configuration-by-web-portal-category/network-access-points-nap/sip-nap-polling.md)
* [Accessing Information about Registered Users](/configuration-details/configuration-by-web-portal-category/routing-scripts/development-guides-and-tutorials/accessing-information-about-registered-users.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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://prosbcdocs.telcobridges.com/configuration-details/configuration-by-use-case/local-site-survivability.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
