VoIP.info Provider research

Nextiva Trunking: registration, call paths and support boundaries

Separate onboarding credentials, PBX registration, customer-owned routes, purchased call paths and portal failover using current first-party evidence.

Reviewed 2026-10-05Current Nextiva SIP Trunking product page and support articles, last updated November 2025 and reviewed October 5, 2026; no account, quote, order, PBX, credential, registration, number, route, call path, media, failover, emergency workflow, message, price, availability, compatibility or support response was testedIntermediateDocumentation based · not lab tested

Start with the exact non-hosted trunk service

Nextiva describes Trunking as a non-hosted service connecting a local or enterprise PBX to its SIP infrastructure. Keep that service separate from a hosted user seat, Nextiva application or complete cloud PBX. A brand relationship or a PBX name on a compatibility list is not proof that one software release, module version or custom dialplan is supported.

For first-time setup, Nextiva directs trunking customers to submit a support case with PBX manufacturer and model. Onboarding supplies a pilot user or number, authentication name, authentication password and domain. Preserve those four values, the intended PBX and the credential owner separately. Do not expose the password, complete registration string or reusable Authorization data in shared traces.

Documented service facts

Reviewed 2026-10-05. Compare SIP trunk services →

Outbound authentication

Documented

Nextiva 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

Documented

The 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

Documented

Numbers 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

Documented

Nextiva 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 verified

The 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

Documented

Nextiva'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 verified

The 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 verified

The 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

Documented

Nextiva 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

Documented

Nextiva 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 verified

Nextiva 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

Documented

Nextiva 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 verified

The 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.

Treat registration and routing as different owners

Nextiva says support can validate PBX registration but is not responsible for configuring inbound or outbound routes. Record DNS resolution, transport, REGISTER request, challenge, authenticated retry, final response and current binding as one evidence chain. A current registration proves neither that an inbound number is assigned nor that an outbound route selected the trunk.

Additional numbers are assigned through support. For inbound service, retain the assigned number, arriving Request-URI and identity headers, matched FreePBX or Asterisk endpoint, inbound route and final destination. For outbound service, retain the digits entered, route match, normalized digits, selected trunk, identity and final SIP response. Avoid a catch-all route that hides number-format or endpoint-identification errors.

Size call paths and media separately

The current FAQ describes one purchased trunk line as one simultaneous inbound or outbound call path; once the purchased count is occupied, another call is rejected. That is active-call capacity, not registered-device count, call-start rate, network bandwidth, PBX capacity or a load-test result. Document the account entitlement and expected rejection behavior before any bounded concurrency test.

The FAQ names G.711 mu-law as the supported codec and specifies 100 Kbps per call as a planning requirement. Retain the actual SDP offer and answer, selected payload, RTP endpoints, DTMF events and packet observations. A bandwidth estimate does not prove quality, and ordinary voice documentation does not establish T.38 fax, modem handling or recording behavior.

Verify failover triggers and independence

Nextiva documents portal forwarding fail-overs and automatic redirection when a PBX is offline. Preserve the configured primary destination, alternate destination, trigger, observed SIP response or timeout, timestamp and resulting call path. The reviewed pages do not specify every response class, retry interval, health signal or established-call behavior. Treat failover as a new-call control until account documentation and authorized testing prove more.

A forwarded destination is not independent merely because it is a different number. Check whether PBX, power, internet access, Nextiva account, upstream carrier and destination device remain shared. Use a noncritical number and an independent communication path during a bounded exercise, then restore and verify normal routing.

Resolve emergency, protection and number gaps before cutover

Nextiva documents E911 controls for multiple sites, but the reviewed pages do not establish the exact eligible outbound identity, dispatchable-location workflow, callback path, nomadic-use rule or approved test procedure for one account. Confirm the current process for every site and number, use only the approved non-emergency validation path and keep an independently tested fallback.

The public setup and FAQ pages reviewed here do not publish a complete customer-facing TLS, certificate-validation, SRTP, keying or downgrade contract. Obtain current parameters and verify the negotiated signaling and media legs before describing a call as protected. Likewise, require a dated serviceability and port result rather than treating general DID, toll-free or porting language as inventory.

Keep commercial and operational evidence dated

The product page presents metered and unmetered models and directs buyers to a personalized quote. Do not copy a displayed price into a budget without a dated quote that covers call paths, usage, destinations, DIDs, toll-free service, porting, failover, E911, taxes, support, commitments, renewal and termination. The reviewed trunk sources also do not establish SMS or MMS entitlement on trunk numbers.

The portal is documented for numbers, caller identity, PBX options, call history, forwarding fail-overs and multi-site E911, while route configuration remains with the customer administrator. Preserve redacted portal state, PBX configuration ownership, timestamps, call records and rollback. No account, quote, order, PBX, credential, registration, number, route, call path, media, failover, emergency workflow, message, price, availability, compatibility or support response was tested for this guide.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.