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 case.
Configuration steps
Follow the instructions for Configuring a Hosted PBX.
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.
Set SIP Domain → Forwarding Parameters → Local Site Survivability to Cached contacts only.
4. Change the default register values on the domain:
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:
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/<version>/apps/gateway/:
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.
Routing scripts read the same data through params[:registered_user] and params[:calling_registered_user]. See Accessing Information about Registered Users 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:
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
Last updated
Was this helpful?