Freeze one service, call and observation window
Record UTC and local time, customer and partner labels, region, product and order identifiers, site, access type, portal tenant and inventory time, trunk label, assigned numbers, PBX and SBC versions, direction, called and calling values, expected route, first response, answer and audio result. Redact credentials and unnecessary subscriber data.
Preserve last-known-good time and recent order, port, peer, access, firewall, certificate, PBX, identity, channel, failover or fraud-policy change. Classify the first unexpected boundary before changing multiple systems.
Prove the handoff and loaded trunk state
Compare the accepted order and implementation record with portal inventory and the PBX or SBC configuration actually loaded. The reviewed public records do not publish one universal registrar, authentication model, peer set, port, firewall range or fallback contract. Obtain account-specific values through the authorized portal, partner and support path.
An enabled portal row, reachable peer, registered object, accepted transaction and completed call remain separate states. Do not copy credentials or network values from another NUSO service or tenant.
Separate channel, fraud and provider responses
For a rejected start, preserve purchased channel allocation, active-dialog count, new-attempt time, PBX resources, provider response, destination response, fraud metric window, risk score, alert and any restriction. NUSO’s public page describes monitoring but does not disclose one account’s thresholds or automatic actions.
Do not generate load or suspicious traffic to discover limits. A 403, 486, 503, timeout or local rejection can have different owners; retain the first response and support finding before changing identity or capacity.
Trace number delivery and failover independently
For inbound failure, prove number assignment or port state, provider attempt, delivered called value, normal route, PBX receipt, alert and answer. If failover is expected, also preserve feature enrollment, eligible number, trigger, alternate destination, provider action and restoration.
NUSOflex is described for inbound PSTN impairment; do not infer outbound rerouting, customer-access survival or established-call continuity. A status notice or alternate completed call does not prove the failing number followed the intended route.
Follow TLS, SIP, SDP, SRTP and audible media
For the same authorized call, record DNS and route result, firewall and NAT state, TLS peer identity and alert, SIP request and response sequence, SDP offer and answer, SRTP negotiation, packet directions, decoding and listener result. Preserve every observation point.
The HIPAA page’s TLS and SRTP statement is product evidence, not proof of one handshake or media stream. Do not invent peer names, credentials, certificates, ciphers, codecs, firewall addresses or PBX compatibility.
Retest one correction and bound portal, support and emergency evidence
Apply one authorized correction, repeat the affected ordinary call and an unaffected control, and retain order, portal, signaling, route, answer, both media directions and hangup evidence. For escalation, record ticket, sanitized artifact, provider finding, action and verified restoration separately.
For emergency readiness, verify the exact eligible number, registered location, authorized identity, callback, PBX and provider route, power, access and independent calling method through the provider-approved non-live process. Never place an uncoordinated live emergency call. No NUSO service, failover, fraud event, call, media path or emergency outcome was tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- NUSO — SIP Trunking product page ↗
- NUSO — Platform Services ↗
- NUSO — HIPAA compliance and SIP Trunking security responsibilities ↗
- NUSO — customer support contacts ↗
- NUSO — technical support and network-status path ↗
- NUSO — policies, programme documents and customer-service contact ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.