Contain the recovery host and preserve the first evidence
If a restored system is competing with production, block its carrier-facing signaling and media egress at the narrowest known network boundary and prevent phones or provisioning systems from reaching it. Keep management access through a separate controlled path. Coordinate with the carrier when a shared public address, private circuit or provider-side binding means local isolation may not immediately reclaim service.
Preserve timestamps, recovery and production addresses, public NAT identity, carrier edge, registration state, affected numbers, call IDs, CDRs and packet or log evidence permitted by policy. Do not delete the restored trunk, wipe logs, reboot both PBXs or change carrier credentials everywhere before establishing which system and path originated the traffic.
Distinguish registration, IP authorization and static routing
A registered trunk, an IP-authenticated trunk and provider delivery to a configured SIP URI fail differently. Asterisk documents outbound registrations as separate objects that can be listed with pjsip show registrations; it also notes that an outbound registration is not tied automatically to an endpoint. Record each registration name, state, server URI, client URI and transport, then map it to the FreePBX trunk.
For IP-authenticated service, compare the source address seen by the carrier with the public or private egress of both hosts. For inbound delivery, capture the provider destination, DNS answer and receiving listener. An unregistered restored PBX can still send or receive calls when the provider trusts its source or routes to its address.
Identify the loaded PJSIP objects and their owner
Use read-only Asterisk state such as pjsip show endpoint <name> and the corresponding registration, AOR, contact, auth, transport and identify objects. The Asterisk troubleshooting guide uses endpoint and contact output to prove loaded relationships; it does not establish which FreePBX form generated them. Compare the loaded state with FreePBX trunks, routes and generated configuration while preserving the management boundary.
If the loaded object has no matching intended FreePBX owner, capture that discrepancy before Apply Config or restart. Do not edit generated pjsip.conf fragments as a durable repair. Determine whether the archive restored a trunk, the target retained a pre-existing object, a conversion created new PJSIP objects or an external include supplied the state.
Trace the first unintended call leg
Choose one affected call and correlate carrier record, FreePBX or Asterisk CDR, call ID, source and destination numbers, route, trunk, SIP tuples, SDP addresses and hangup owner. For inbound traffic, prove which carrier destination reached which PBX and which inbound route selected the final destination. For outbound traffic, prove which extension, application, restored schedule or external integration originated the call and which outbound route and trunk carried it.
Do not infer ownership from the displayed caller ID, a green trunk icon or the presence of an endpoint contact. Caller identity can be copied, registration can move between hosts, and both systems can produce similar dialplan names.
Remove persistent production reachability in the restored owner
After containment and attribution, disable the copied production trunk, route or scheduled origin in the recovery system through its supported FreePBX owner and Apply Config. Keep the network deny in place while confirming that the corresponding loaded registration and endpoint state changed. If production credentials were exposed or the carrier cannot distinguish the hosts, coordinate a credential rotation or provider-side binding change with a rollback window.
A CLI unregister can change a current registration state but is not a persistent FreePBX correction; a service reload can recreate it. Likewise, blocking one SIP destination does not neutralize DNS alternatives, IP-authenticated egress, inbound delivery, email jobs or call files. Reconcile every admitted external path before relaxing containment.
Recover production before testing the rehearsal target
Confirm the intended production PBX owns the registration or provider binding, receives the authorized inbound numbers and originates approved outbound calls. Use a bounded acceptance matrix for internal, inbound and outbound calls, two-way audio, DTMF, transfer, voicemail and hangup. Check a neighboring unaffected number or trunk so a narrow repair does not hide wider routing damage.
Use the carrier's approved emergency-services test procedure only after registered location, callback identity and route ownership are verified. Do not place an uncoordinated emergency call to prove that the restored PBX is offline.
Rebuild the restore test as an isolated exercise
Keep the restored host contained and return to the restore-testing procedure. Replace production trunks with a test identity or approved carrier test path, use isolated endpoints and make external access explicit and reversible. Record the control that prevents future archive imports, restore hooks, DNS, NAT or provisioning changes from reconnecting the target.
Close with the root cause, affected interval, calls and numbers, production recovery evidence, credential action, remaining uncertainty and revised recovery runbook. This diagnostic is documentation-derived and no PBX, provider, registration or call was tested.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Sangoma Backup and Restore for FreePBX 15 and later ↗
- FreePBX Backup & Restore release/17.0 metadata ↗
- FreePBX Core release/17.0 metadata ↗
- Sangoma FreePBX 17 FAQ ↗
- Asterisk configuring outbound registrations ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk PJSIP objects and relationships ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.