Freeze one service and one affected call window
Record UTC and local time, customer and tenant, site or group, trunk name, order and activation reference, access handoff, ESBC or direct peer, authentication mode, PBX or SBC 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, registration, capacity, forwarding, trunk-group, number, PBX, firewall or E911 change. Diagnose the first unexpected boundary before changing several systems.
Compare read-only portal state with the loaded edge
Select the exact Blue Platform site or group and trunk. Compare Access Details, network point of presence, ESBC or direct-peering label and registration checkbox with the PBX or SBC configuration actually loaded. Treat portal visibility and effective runtime state as separate records.
If account-specific values are unclear, use an authorized support path. Do not infer a registrar, peer, username, password, source address, port, transport, certificate or compatibility from the public product page.
Interpret capacity and bursting without manufacturing load
Record the total simultaneous-call maximum, incoming and outgoing controls, active dialogs, new-attempt time, local channel usage and first provider response. A zero directional value means no separate directional cap is configured; it is not zero-call capacity. Confirm whether bursting was ordered and enabled rather than assuming it from a marketing statement.
Do not generate production load to discover limits. A 486, 503, timeout or local rejection can have different owners; retain the exact first response and support finding.
Trace normal delivery, forwarding and reroute separately
For inbound failure, preserve DID association, provider attempt, delivered called value, PBX receipt and normal destination. If Always or Unreachable forwarding is expected, also record the saved destination, mode, delay, trigger, switch action, alternate alert and answer. For a trunk-to-trunk reroute, retain both sites and trunk names.
Whole-trunk forwarding differs from DID-level forwarding, and portal DID forwarding can override PBX settings. A configured fallback does not prove the failing call used it or that every number shares the same destination.
Follow SIP, SDP, packets and audible media for the same call
At each authorized observation point, record DNS and route result, firewall or VLAN state, registration exchange when applicable, SIP request and response sequence, SDP offer and answer, packet directions, decoding and listener result. Keep ESBC, direct-peer and public or private access paths distinct.
A registered object, portal status, answered SIP dialog, packets and usable two-way audio remain separate evidence. Do not invent codecs, DTMF mode, fax behavior, encryption, firewall ranges or PBX support.
Retest one correction and escalate with bounded evidence
Apply one authorized correction, repeat the affected ordinary call and an unaffected control, and retain order, portal, edge, signaling, route, answer, both media directions and hangup evidence. Record status notice, ticket, sanitized artifact, provider finding, action and verified restoration separately.
For emergency readiness, verify the exact number, dispatchable location, callback, notification and route through the provider-approved non-live process. No Telesystem service, forwarding event, call, media path, emergency outcome 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.
- Telesystem — SIP Trunks product page ↗
- Telesystem — SIP Trunk Administration for Tenant Admins ↗
- Telesystem — SIP Trunk DID Forwarding quick reference ↗
- Telesystem — E911 compliance guidance ↗
- Telesystem — network status and support paths ↗
- Telesystem — account support and escalation contacts ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.