Freeze the current support handoff before loading a PBX template
Nextiva's October 13, 2026 setup article says first-time trunking customers request PBX credentials through a support case and receive a pilot user or number, authentication name, authentication password and domain. Preserve the case, PBX manufacturer and model, each issued field, issue time and intended PBX as one redacted handoff. A product page, reseller worksheet or remembered domain is not a substitute.
The setup page warns that linked PBX guides may not match the current interface. The retained Avaya guide is a 2015 reference configuration with a named domain, UDP port and codec examples. Use it to understand fields, not to overwrite a current support-issued domain or capability. Record current support confirmation whenever the dated guide and current FAQ differ.
Documented service facts
Reviewed 2026-10-05. Compare SIP trunk services →
Outbound authentication
DocumentedNextiva onboarding supplies a pilot user or number, authentication name, authentication password and domain after a support case. Preserve those fields separately and do not substitute a hosted-seat login or a number from another PBX.
SIP registration
DocumentedThe reviewed setup material describes a PBX registration and says Nextiva can validate that registration. Registration success does not establish inbound or outbound route configuration, which Nextiva explicitly leaves with the customer PBX administrator.
Inbound delivery
DocumentedNumbers are assigned to the SIP trunk through Nextiva support, while the customer PBX owns the inbound route and final destination. Portal number state, an arriving INVITE, PBX route selection and user-visible ringing remain separate evidence stages.
Inbound failover
DocumentedNextiva documents portal forwarding fail-overs and automatic redirection when a PBX is offline. The reviewed pages do not define every qualifying SIP response, timeout, retry interval or the behavior of an established call, so those controls require account-specific confirmation and bounded testing.
Number and regional availability
Not verifiedThe product page describes direct-dial, toll-free and number-porting options, but exact inventory, portability, address eligibility and international availability for a specific account were not established. Require a dated serviceability and port result for each number.
Audio codecs
DocumentedNextiva's current Trunking FAQ names G.711 mu-law as the supported codec and specifies 100 Kbps in each planning allowance per call. That published bandwidth figure is not a measured quality result and does not establish packetization, DTMF, jitter tolerance or every access-network overhead.
T.38 fax
Not verifiedThe reviewed trunking pages do not establish T.38, G.711 pass-through, modem support or a fax acceptance procedure. Qualify the exact number, direction, gateway, document set, error correction, switchover and fallback separately.
Signaling and media encryption
Not verifiedThe reviewed public setup and FAQ pages do not publish the exact customer-facing TLS, certificate-validation, SRTP, keying or downgrade contract. Obtain current account parameters and verify the negotiated signaling and media legs before describing a call as protected.
Concurrent calls and burst
DocumentedNextiva documents each purchased trunk line as one simultaneous inbound or outbound call path, with additional calls rejected once the purchased count is occupied. This active-call capacity does not establish call-start rate, burst handling, media bandwidth, PBX capacity or guaranteed acceptance under load.
Emergency calling
DocumentedNextiva documents E911 controls for multiple sites in the Trunking Portal. The reviewed pages do not establish the exact eligible caller identity, dispatchable-location workflow, callback path, nomadic-use rule or approved test procedure for one account; confirm each before cutover and keep an independent fallback.
Pricing model
Not verifiedNextiva publicly describes metered and unmetered plans and directs buyers to a personalized quote. A displayed web offer does not establish the current account price, included destinations, fair-use terms, number fees, porting, taxes, support, renewal or termination terms; obtain a dated quote and contract.
Administration and support
DocumentedNextiva documents portal management of numbers, caller identity, PBX options, call history, forwarding fail-overs and multi-site E911. Support can supply credentials and validate PBX registration, but the current setup article says inbound and outbound routes remain the customer's responsibility.
SMS and MMS
Not verifiedThe reviewed SIP-trunk sources do not establish SMS or MMS entitlement on trunk-assigned numbers. Verify number capability, registration, consent controls, application or API path, throughput, retention and fees separately from PSTN voice.
Keep credentials, REGISTER and the live binding separate
The pilot number, authentication name, password and domain are different values. A PBX can send REGISTER to the wrong domain, authenticate with the wrong identity, publish an unusable Contact or leave an old binding current. Capture DNS selection, transport, REGISTER, challenge, authenticated retry, final response, Contact, expiry and provider-visible state separately. Redact passwords and reusable Authorization material.
Nextiva says support can help validate PBX registration but is not responsible for configuring inbound or outbound PBX routes. Registration is therefore a connectivity checkpoint, not proof that a DID is assigned, an inbound route matches, an outbound pattern selects this trunk or media works.
Prove DID assignment before changing an inbound route
The current setup page says additional phone numbers for PBX routing require a support case, and the FAQ separately says phone numbers are assigned to the trunk through support. Keep account inventory, support assignment, provider attempt, customer-edge receipt, Request-URI, endpoint identification, inbound-route match and final destination as distinct evidence.
Nextiva's general inbound-failure page says a universal not-in-service result can mean that a number is unassigned and requests recent examples with calling number, called number, time zone and observed behavior. That hosted-voice guidance is not a trunk route contract, but its evidence format is useful. Do not replace an unproven provider assignment problem with a catch-all PBX route.
Separate outbound routing, identity and purchased call paths
For an outbound failure, record the digits entered, normalization, matched PBX route, selected trunk, From and asserted identities, provider response and downstream result. An authenticated registration does not show which outbound route ran or whether the presented number is authorized. The dated Avaya guide's field and header examples remain PBX-specific rather than universal current values.
The FAQ describes one purchased trunk line as one simultaneous inbound or outbound call and says the next attempt is rejected when the purchased total is occupied. Treat that as account capacity, not a registered-device count, call-start rate, PBX limit or proof of the exact response code. Reconcile entitlement, active calls and the observed attempt before increasing capacity.
Version media and network guidance instead of flattening it
The current trunk FAQ names G.711 mu-law as the supported codec. The legacy Avaya guide also lists G.711 A-law and G.729 in its old reference test, so those documents cannot be flattened into one timeless codec set. Preserve the current account answer, SDP offer and answer, selected payload, DTMF method, media endpoints and decoded-audio result.
Nextiva's networking article is written for Nextiva Voice and phones, including far-end NAT and a 5062–5090 safeguard. Do not copy that entire endpoint rule set into a trunk firewall. Apply the current trunk domain, resolved destinations, transport and media policy supplied for the account, then verify packets. Bandwidth guidance is a planning input, not proof of quality.
Test failover, emergency identity and recovery as separate controls
The FAQ says the portal can manage forwarding fail-overs and E911 options for multiple sites, while the product page mentions redundant SIP servers. Those statements do not define every trigger, response code, timer, destination, restoration rule or established-call behavior. Preserve the configured primary, alternate, trigger evidence, new provider attempt, resulting destination and rollback for an authorized noncritical test.
A forwarding destination, second Internet path and redundant provider server solve different failures. E911 site settings also do not prove that one trunk caller identity has the intended dispatchable address, callback path or approved test procedure. Confirm the account-specific process and keep an independently tested emergency alternative. No Nextiva service behavior was laboratory validated for this guide.
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.