Freeze one call and the intended route definition
Record UTC and local time, inbound traffic type, calling and called identities, Infobip number or source, intended route ID, complete destination list, priorities, weights, allowed windows, enabled states, recent change time and exact observed destination. Preserve the inbound call leg, every outbound leg, correlation identifier, dialog ID and SIP Call-ID where available.
Classify the symptom narrowly: the wrong route was selected; a destination was ineligible; the trunk was Administrative Down; OPTIONS marked it out of service; a connection attempt took time; the reachable PBX did not answer before its timeout; a SIP response advanced the route; or the next destination was correct but its call leg or media failed.
Prove route selection before testing the trunk
Check whether the inbound number has a static Call Routing assignment or relies on filter-based selection. Reproduce the exact inbound type, from, to and relevant SIP headers in the Route Simulator, retaining whether disabled routes were included and whether the configuration-change propagation window had elapsed.
The simulator identifies the matched route and execution order without sending live traffic. If it chooses the wrong route, fix the number assignment, route priority or first matching filter through the configuration owner. Do not change SIP-trunk transport or PBX matching to compensate for a route-selection error.
Explain every skipped or ineligible destination
For each earlier destination, preserve the enabled state, administrative state, Allowed Time Window result, priority, weight and destination type. Entries at the same priority can receive a weighted share; a different selected entry at that priority is not necessarily failover. A lower-priority entry requires an execution reason for every earlier eligible entry.
If the SIP entry rewrites the destination with an optional username, compare that value with the PBX Request-URI and inbound-route expectation. A reachable trunk can still deliver an identity the PBX does not route, which is different from provider-side skipping.
Separate OPTIONS state from the current connection attempt
Record whether OPTIONS polling is enabled, the last successful and failed poll observations, the time the trunk entered or left out-of-service state and the transport. An Administrative Down or already out-of-service trunk is skipped immediately. Without OPTIONS, an unreachable trunk can incur the documented per-call delay and is not remembered as out of service by that mechanism.
With OPTIONS enabled, the initial failure can still wait through UDP or TCP/TLS timers before polling-derived state makes later calls advance without delay. Do not reset the trunk merely to clear the symptom; retain the transition timestamps and compare a bounded new call after recovery.
Measure connection and answer timers on separate clocks
Capture DNS resolution, socket attempt, INVITE transmission, first SIP response, provisional progress, final response and answer time. The route destination timeout applies to a reachable destination as an answer timer. It does not replace the separate connection or reachability behavior.
If the customer edge receives the INVITE, correlate the PBX endpoint or trunk match, context, route, ringing target and final SIP response. Change only the first demonstrated divergence. Do not lengthen every timer, return a fabricated provisional response or disable protection controls to keep a destination first.
Reconcile logs, packets, media and restoration
Export the inbound and attempted outbound call legs, retaining route, trunk name, trunk ID, correlation identifier and dialog ID. A disabled SIP destination may have no attempted outbound leg; document its state rather than treating that absence as a missing provider record. Correlate provider timing with the edge capture, PBX logs, SIP Call-ID, SDP and both RTP directions.
After the bounded correction, wait for documented configuration propagation, rerun the same simulator input, place authorized primary and alternate calls and confirm restoration to the intended destination. A selected or bridged leg is not proof of intelligible audio, emergency suitability or end-to-end resilience. No account, route, SIP exchange, packet, failover or 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.
- Infobip SIP trunking ↗
- Infobip SIP trunk setup ↗
- Infobip Call Routing overview ↗
- Infobip Call Routing route creation ↗
- Infobip inbound route selection ↗
- Infobip route execution and troubleshooting ↗
- Infobip SIP Trunks API ↗
- Infobip Voice reports ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.