Freeze one failed call and the current handoff
Record UTC and local time, direction, calling and called numbers, PBX and provider Call-ID where available, exact symptom, current pilot number, redacted authentication identity, support-issued domain, intended PBX, support case, assigned DID list and purchased call paths. Capture the first response and elapsed time before changing the trunk, routes and firewall together.
Classify the failure narrowly: registration is absent or stale; registration is current but the DID is not assigned; the provider attempt misses the customer edge; the PBX identifies the wrong endpoint; the inbound route misses; the outbound route selects another trunk; identity is rejected; capacity is occupied; signaling succeeds but media fails; or failover selects an unexpected destination.
Reconcile issued credentials, DNS and the live REGISTER transaction
Compare the loaded pilot or user, authentication name and domain with the latest Nextiva support handoff for this PBX. Resolve the issued domain from the affected network and retain answers and TTLs, then correlate REGISTER, challenge, authenticated retry, final response, Contact and expiry. A dashboard row or PBX green icon is not the transaction.
Do not copy the legacy Avaya guide's domain, port or codec values over current account data. If credentials were regenerated, identify every PBX that used the old secret and rotate through a controlled plan. Keep secrets and reusable challenge responses out of general logs and tickets.
Prove provider assignment and the inbound PBX match separately
For the called DID, obtain the provider inventory and support assignment to this trunk, including case and effective time. Then determine whether Nextiva made an attempt and whether it reached the customer edge. Only after edge receipt inspect source, destination, Request-URI, To and asserted identity, endpoint identification, context, first inbound-route match and destination.
A registered pilot number does not establish assignment of every additional DID. A not-in-service result, provider call-history entry, firewall packet and PBX route match are separate observations. Preserve recent calling number, called number, time zone and behavior in the support evidence.
Follow the outbound route, identity and capacity decision
For outbound service, retain the digits entered, normalization, route pattern, selected trunk, From and asserted identities, challenge result and final SIP response. Compare the presented number with the account-authorized identity rather than substituting the pilot or an arbitrary DID until one call happens to pass.
If failures start only under load, reconcile purchased call paths with concurrent inbound and outbound calls at that instant. Do not infer a universal rejection code from the FAQ. PBX channel count, registered objects, provider entitlement, active calls and the result of this attempt remain separate evidence.
Test current media and network policy without importing endpoint defaults
Compare the account-approved signaling and media profile with the SDP offer and answer, selected G.711 mu-law payload, DTMF method, RTP endpoints and both packet directions. The legacy Avaya reference lists older codec examples; current support or order evidence controls. A SIP answer is not two-way audio, and packets are not proof of intelligible audio without an authorized endpoint observation.
Use the generic networking page only as an investigation lead for NAT, SIP ALG, loss and jitter. Do not open all phone-service ports for a trunk. Prove the current domain, resolved addresses, transport, firewall decision and media policy for the actual PBX.
Correct the first divergence and verify restoration
Change only the first proven mismatch: support-issued field, DNS result, registration object, DID assignment, endpoint identification, inbound route, outbound pattern, caller identity, call-path entitlement, firewall rule, codec or media address. Provider-owned corrections need a Nextiva case and effective state; PBX and network changes need their own approval, backup and rollback.
Repeat controlled inbound and outbound calls, then verify registration, assignment, route, identity, answer, two-way audio, DTMF when required, call history, failover and restoration separately. No Nextiva account, support case, PBX, credential, number, route, packet, media stream, failover, emergency workflow or live call was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Nextiva SIP Trunking product page ↗
- Set Up your Nextiva Trunking Account ↗
- Nextiva Trunking FAQs ↗
- Nextiva Networking Guidelines ↗
- Nextiva Inbound Call Failure ↗
- Nextiva Outbound Call Failure ↗
- Nextiva Avaya PBX SIP Trunking Setup Guide (legacy reference configuration) ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.