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.
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
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:
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:
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:
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.
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 OKand 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.
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.
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.
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:
Configuration
See Local Site Survivability Configuration Instruction 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.
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
References
Last updated
Was this helpful?