AVOXI SIP trunking: outbound identity, inbound SIP URIs and terminal responses

Inventory outbound trunks and inbound SIP URIs separately

AVOXI documents SIP trunks for outbound termination and SIP URIs for inbound forwarding. Record the outbound trunk name, subdomain, authentication type, transport and PBX owner separately from every inbound SIP URI, routing rule, assigned number and selected data center. A working outbound call does not prove that an inbound number targets the intended URI.

The outbound guide is for PBXs, SBCs and similar systems rather than individual SIP-phone registration. Preserve the exact tenant model before adding registration checks or changing inbound routing.

Prove the selected outbound authentication type

An individual AVOXI trunk selects one authentication type: Basic username and password, authorized source IP, SIP-header authentication or the documented number option. A shared platform may need additional identity information, but the provider explicitly says one type is selected per individual trunk.

Capture the effective portal selection and one redacted INVITE. Compare the provider-observed public source after NAT, challenged identity or private header ownership without publishing reusable values. Authorization does not establish destination permission, caller identity acceptance or media.

Follow each number through its routing target

An inbound SIP URI contains a caller-ID format, public domain or IP target, listening port and protocol. It becomes a live number path only when selected as a forwarding-rule target. Preserve the number, enabled rule, target type, named URI, preview and effective destination before changing the PBX.

AVOXI warns that editing an existing SIP URI changes its settings for all applicable numbers. A shared URI edit and a number-specific target change therefore have different blast radii and rollback plans.

Read terminal codes as an explicit stop policy

The inbound workflow allows optional terminal SIP response codes from 400 through 699 and says an entered code results in call termination. Retain the effective list and one call’s final response. Do not infer universal advancement, retry, timeout or alternate-target behavior for responses not explicitly configured as terminal.

Keep provider receipt, endpoint attempt, response, rule decision and any next target separately observable. A PBX rejection can be intentional while the number-to-rule mapping remains correct.

Treat the on-demand SIP URI test as bounded evidence

The portal can place an on-demand SIP URI test using a selected number, an AVOXI support caller and a chosen data center. The result is reported as pass or fail and can expose a SIP error code. That proves only the tested URI, provider data center, destination and time window.

It does not prove the production caller identity, every assigned number, routing-rule ordering, customer access diversity, established-call survival or two-way media for later calls. Preserve test and production evidence separately.

Correlate network, PBX and media evidence

AVOXI publishes data-center-specific signaling sources, UDP 16384–25999 media, UDP/TCP signaling and TLS/SRTP options. Use the current page or tenant setup instructions rather than an old firewall list. Verify the selected data center, edge receipt, Asterisk endpoint identification, context, first dialplan match and response before widening access.

Then inspect offer and answer SDP, RTP endpoints, negotiated codec and decoded audio. SIP acceptance is not proof of two-way media, and a published address list is not proof that every address appears on every route. No AVOXI service, account, packet or call was tested for this guide.

Diagnose an AVOXI number, URI and response together

Use the AVOXI inbound SIP URI diagnostic to correlate the number rule, named URI, provider test, actual attempt, response, PBX match and media.