Freeze one call and every effective owner
Record the called AVOXI number, timestamp and timezone, enabled forwarding rule, target type, SIP URI name, preview, protocol, destination, port, caller-ID format, selected data center and terminal-code list. Add the provider call or test identifier, attempt, response, edge receipt, PBX match, route, answer, SDP and audio result.
Export the effective settings before editing. A remembered URI or PBX route cannot prove the number’s current target.
Confirm the number selects the intended SIP URI
Open the affected number and verify that its enabled rule targets SIP and the intended named URI. Compare the URI preview with the actual public destination and listening port. If no AVOXI attempt exists, preserve that bounded negative evidence instead of widening the PBX or firewall.
Treat bulk number changes and edits to a shared SIP URI separately. AVOXI says an existing URI edit changes settings for all applicable numbers.
Classify the provider test and production call separately
Run the authorized on-demand SIP URI test only after saving the intended URI. Retain its selected number, support caller, data center, pass or fail result and any SIP error code. Then place one controlled production inbound call and correlate it independently.
A passing test does not prove production caller identity, rule selection, every data center, later availability or media. A failing test is not proof that the number’s routing target is wrong.
Apply terminal responses only where configured
For the actual attempt, record no response, transport failure, elapsed timer or final SIP response. If a 400–699 code appears in the effective terminal list, preserve the resulting termination. Do not invent a universal next-target matrix for codes absent from the list.
Separate provider attempt, customer-edge receipt, PBX response, provider rule decision and any later attempt. One final response does not establish the behavior of another number or rule.
Prove PBX matching and media after edge receipt
At the customer edge, compare the source and Request-URI with the intended AVOXI data center and SIP URI. In Asterisk or FreePBX, preserve the endpoint-identification result, assigned context, delivered number form and first matching inbound route.
If signaling succeeds, inspect offer and answer SDP, observed RTP, codec and decoded audio in both directions. A correct URI target does not establish a working media path.
Correct the earliest mismatch and bound the result
Change only the demonstrated owner: number rule, target type, URI, protocol, port, caller-ID format, terminal list, firewall, PBX identification, inbound route or media policy. Repeat the same test and production call, then verify the intended result and rollback scope.
Remove temporary captures and rules. This does not prove every number, response, data center, failover path, compatibility, availability, pricing or established-call survival. No AVOXI account, object, PBX, packet or call was inspected or tested.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- AVOXI outbound SIP trunk configuration ↗
- AVOXI inbound SIP URI forwarding ↗
- AVOXI outbound SIP trunk diagnostic ↗
- AVOXI SIP forwarding and trunking overview ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.