Freeze one inbound call and the effective trunk state
Record the dialed number, timestamp and timezone, account, trunk type and assigned domain, inbound region, number-to-trunk link, every SIP URI, priority, timeout, transport and SRTP choice, Vonage call identity, SIP Call-ID, provider attempts, PBX match, answer, media and caller outcome. Redact credentials and customer identifiers.
Classify the first disputed boundary: number association, trunk selection, region, URI value, priority, timeout, DNS, transport, firewall, PBX identification, inbound route, answer or media. Do not change all of them together.
Prove the number link and ordered URI set
Verify that the called number is linked to the intended trunk; linking can replace an earlier application or domain association. Then export or capture the saved URI rows in effective priority order. Use unique priorities because equal values do not guarantee delivery order.
Confirm each timeout: Vonage accepts 2,000 to 20,000 milliseconds and uses 5,000 milliseconds when the field is empty. Confirm each destination, optional user and port, and remember that the dashboard guide says the URI field does not support IPv6.
Separate DNS, reachability, timeout and final response
Resolve every configured FQDN from the relevant context and preserve the answers and observation time. Match the selected address, destination port and transport to firewall and listener evidence. A DNS answer, open port or OPTIONS response is narrower than a delivered inbound INVITE.
For the disputed call, record whether the destination produced no response, a transport error, an elapsed timeout or a final SIP response. The public dashboard guide defines priority and timeout but not one universal response-code advancement matrix, so do not infer that every rejection must select the next URI.
Join Vonage attempts to Asterisk or FreePBX
Match the provider timestamp and call identity to an authorized edge capture and PBX logging. If the INVITE arrived, preserve source and destination address, transport, Request-URI, called number, PJSIP endpoint identification result, authentication result, first matching FreePBX inbound route or Asterisk context, and the exact PBX response.
Do not add outbound registration merely to repair inbound delivery unless the selected configuration explicitly requires it. Do not copy an example IP list or legacy object blindly; compare the current Vonage guide, current service addresses and the loaded PBX version.
Treat answer and media as later boundaries
If the PBX sends 2xx, prove the intended endpoint or application handled the call. Then record SDP offer and answer, selected codec, RTP endpoints, packet counters and decoded audio in each direction. A completed SIP dialog does not prove ringing treatment, two-way audio or DTMF.
Keep configured TLS and SRTP separate from observed transport and media negotiation. A provider log or provider-side signaling record cannot by itself establish packet receipt or decoded media on the customer interface.
Correct one owner and retest recovery deliberately
Correct only the first demonstrated owner: number link, trunk object, region, URI, priority, timeout, DNS, transport, firewall, endpoint identification or inbound route. Repeat authorized calls for normal primary delivery, an unreachable primary, the next eligible URI, primary recovery and return to preferred order. Test a reachable primary rejection separately and preserve rollback.
One successful sequence is not a universal failover, active-call continuity, capacity, price, availability or compatibility result. No Vonage account, number, trunk, URI, PBX, packet, media stream 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.
- Vonage SIP technical details ↗
- Vonage SIP Dashboard guide ↗
- Vonage Asterisk PJSIP configuration ↗
- Vonage FreePBX configuration ↗
- Vonage Voice Logs guide ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.