Freeze one order, site and affected call window
Record UTC and local time, customer, contracting affiliate, country, site, service order, start or activation reference, exact Voyant trunk type, access path, IAD or edge, PBX version, direction, calling and called values, expected route, first response, alert, answer, audio and hangup. Redact credentials and unnecessary subscriber data.
Preserve the last-known-good time and recent order, access, line, elastic-policy, number, caller-ID, E911, PBX, firewall or portal change. Diagnose the first unexpected boundary before editing multiple systems.
Compare the order and portal with loaded edge state
Use the authorized service order and account record for the exact trunk, access, numbers, capacity model, authentication or identification, features, country and emergency service. Compare those facts with PBX or SBC objects actually loaded and the path actually selected.
The public pages do not establish one universal registrar, proxy, realm, username, password, source-address rule, port, transport, certificate or media range. Do not copy values from another account or infer trunk health from a successful portal login.
Separate elastic policy, local resources and provider response
Record selected line or elastic-channel policy, active dialogs, local channel usage, offered attempts, call-start times, access capacity and the first PBX or provider response. A dynamically allocated or elastic-service description does not prove unbounded capacity or one account entitlement.
Do not manufacture production load. Distinguish a local resource limit, access congestion, provider policy response, destination busy result, timeout and completed call.
Trace assigned caller identity and number delivery
For outbound caller-ID failure, retain FROM, P-Asserted-Identity, account number assignment, provider rewrite, response and destination display. For inbound failure, preserve number order or port state, provider attempt, delivered called value, PBX match, alert and answer.
A pilot, portal number row, working outbound call or presentation at one destination does not prove authorization, inbound routing, callback identity or every destination display.
Verify the exact E911 record without live emergency traffic
Confirm the affected number, service country, portal E911 status, validated address, effective update, notification recipients, PBX emergency route, callback identity, power and broadband dependencies. Preserve the downloaded and uploaded CSV separately when bulk import is used.
Use only Voyant-approved non-live checks such as the documented 933 workflow when applicable and authorized. Never place an uncoordinated live emergency call or treat a saved portal value as proof of routing.
Correlate status, support and a bounded retest
Align the customer symptom with the exact Voyant status components rather than one overall color, then retain case, affected account and site, sanitized signaling or packet evidence, provider finding and action separately. Apply one authorized correction and repeat the affected ordinary call plus an unaffected control.
A status change, ticket response or accepted SIP dialog does not prove caller identity, two-way media, emergency readiness or restoration. No Voyant service, call, caller-ID result, E911 outcome, 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.
- Voyant — communications products and SIP Trunking ↗
- Voyant — Master Services Agreement ↗
- Voyant — SIP Trunking terms and conditions ↗
- Voyant — VoIP 911 information ↗
- Voyant — Canadian 9-1-1 service notification ↗
- Sinch Community — SIP Trunk E911 bulk import in CAP, August 2024 ↗
- Sinch Community — Voyant/ANPI SIP Trunking STIR/SHAKEN caller-ID changes ↗
- Voyant — support contacts ↗
- Voyant — service status ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.