Freeze the order and failed attempt
Record UTC and local time, exact Superloop product, service order, schedule, site, access, router or SBC, PBX and software, ordered capacity and DIDs, direction, calling and called values, first response, answer and audio result. Redact secrets while retaining field names and retrieval time.
Classify the first unexpected boundary: order, access, firewall, SIP identity, registration or source trust, DID, request, response, dialog, media, platform feature, outage or fault process. Do not replace the ordered SIP Trunk with a TotalTalk or Teams template.
Prove the access and customer edge
Confirm the ordered connectivity, addressing, routing, NAT, firewall and customer/provider demarcation. Compare the actual path with the requirements sheet and implementation record before changing SIP ALG, port forwarding or broad firewall policy.
A working internet session, managed-router status, reachable address or DNS answer does not prove that the SIP identity is accepted. Preserve both sides of the edge and one control flow.
Map issued SIP data to loaded PBX state
Retrieve the current Superloop implementation record and map its registrar or source-trust model, signaling targets, transport, ports, identities, DID format, codecs, DTMF and media ranges to generated configuration and loaded FreePBX or Asterisk objects. Public marketing is not a substitute.
Correlate request, response, SDP and packets by Call-ID. After answer, prove both media directions, selected codec, decoding and audibility separately; do not infer encryption or compatibility.
Trace DID, port and platform ownership
For inbound failure, preserve number ownership, port acceptance, activation, provider attempt, delivered Request-URI or To identity, PBX receipt, first route match and final destination. A temporary port interruption and a persistent routing defect require different evidence.
If a queue, IVR, forwarding or office-hours rule is involved, identify whether the service order assigns it to TotalTalk, Teams, an Inbound service, Superloop, or the customer PBX. Do not transfer family-level platform features into SIP-trunk troubleshooting.
Separate outage, fault class and restoration
Check the current outage surface, then retain the fault ticket, scope, P1–P4 classification, response timestamp, updates, exclusions and closure basis. A provider-declared outage does not prove every observed symptom shares its cause; no posted outage does not exclude a local or unposted fault.
A response or restoration target is not a guarantee, and a closed ticket is not end-to-end recovery evidence. Re-test the original path and an unaffected control, including signaling, answer and both media directions.
Apply one correction and close with bounded evidence
Apply one authorised correction and repeat the ordinary call through the affected service. Preserve access and edge state, loaded PBX objects, SIP exchange, DID match, answer, both media directions, hangup and rollback criteria. Record whether the fault boundary was provider, customer, third-party network or still unresolved.
Validate power, alternate-calling and emergency-location readiness through an approved non-live process; do not place an uncoordinated 000 call. No Superloop service, fault, call, media path or emergency result was tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Superloop — Business VoIP and SIP ↗
- Superloop — Voice specifications data sheet ↗
- Superloop — Business Voice Service Schedule, 10 March 2026 ↗
- Superloop — business support contact ↗
- Superloop — outages and service updates ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.