Freeze one order, site and failed transaction
Record UTC and local time, accepted order and schedule, service location, on-net or off-net scope, redundant or non-redundant access design, handoff, trunk identity, PBX or SBC version, direction, calling and called values, first response, alert, answer, audio and hangup. Redact credentials and unnecessary subscriber data.
Preserve the last-known-good time and recent order, access, number, channel, PBX, firewall, E911 or provider change. Diagnose the first unexpected boundary before editing multiple systems.
Compare the implementation record with the loaded handoff
Use the current service order and implementation handoff for the exact access circuit, demarcation, Ethernet or PRI handoff, signaling target, identity or authentication method, channel quantity and numbers. Compare those facts with the PBX or SBC objects actually loaded and the route actually selected.
Do not copy a registrar, realm, credential, address, port, certificate or media range from another FirstLight customer or from a generic vendor template. Public marketing does not define one universal SIP profile.
Trace access, admission, signaling and both media directions
Align access-interface state, routing, latency or loss observations, active dialogs, new attempts, PBX resources, first SIP response, destination response and completed calls. For inbound failure, follow number state, provider attempt, delivered value, edge receipt and PBX match. For outbound failure, retain selected trunk, calling identity, dialed value, request and response.
Then align SDP, interface packets, NAT or firewall state, decoded payloads and each listener result. G.711 documentation or packets in one direction do not establish accepted signaling or usable two-way audio.
Prove the ordered redundancy boundary
Confirm whether the order includes geo-diverse redundant access loops or a non-redundant loop. Preserve the affected service, failure start, route or loop state, alternate-path evidence, provider finding, answer and media for a bounded authorized test.
Do not use the SIP sheet’s general redundancy or 99.999% language as proof of one order’s SLA. An alternate route, link or answered call does not establish established-call survival, every-number delivery, media quality, primary-path restoration or credit eligibility.
Verify number and emergency records without a live emergency test
Preserve order or port state, number assignment, rate center, registered street address, activation state, callback identity, PBX emergency route, power and broadband dependencies and effective update time. Distinguish an address saved in a workflow from an accepted emergency record and a non-emergency validation result.
The current schedule says activation requires affirmative steps and lists exclusions for soft phones, local inbound numbers and virtual numbers. Do not generalize the older acknowledgement or place an uncoordinated live emergency call.
Correlate support scope and bounded restoration
Retain the exact service object, completion notice, NOC ticket, severity, response, provider finding, action, excused-outage assessment, credit request and restoration time independently. After one authorized correction, repeat the affected ordinary call and an unaffected control, then monitor the same evidence interval.
A completion notice, SLA response, case closure, credit, path change or one successful call does not establish root cause or durable restoration. No FirstLight service, redundancy event, emergency result, incident or support finding was tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- FirstLight — Voice and SIP Trunking ↗
- FirstLight — SIP Trunk info sheet ↗
- FirstLight — Service Schedule A, Voice Services, version 4 (August 21, 2026) ↗
- FirstLight — Standard Terms and Conditions, version 5 (June 16, 2025) ↗
- FirstLight — E911 Acknowledgement, version January 14, 2019 ↗
- FirstLight — Legal, Regulatory, Terms and Conditions ↗
- FirstLight — Customer Support ↗
- FirstLight — Prevent Long Distance Fraud and PBX Hacking ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.