Execute and troubleshoot routes
Route execution
Destinations in a route are tried sequentially, based on their priorities and weights, until a destination can be successfully connected to or until the end of the destination list is reached.
The route execution advances from one destination to the next one based on error conditions and timeouts.
Newly added or modified routes can take up to 5 minutes to become effective and for their definitions to propagate through the system caches.
SIP trunk destinations [#sip-trunk-destinations-route-execution]
The following table summarizes how route advance is handled for both UDP and TLS SIP trunk.
A SIP trunk destination is immediately skipped if it is in Administrative Down status or considered to be out of service (the trunk was configured to use SIP OPTIONS and the SIP OPTIONS polling determined that the trunk is out of service).
Transport type | End user state | SIP OPTIONS enabled | Re-routing delay | Duration to consider the trunk out of service |
|---|---|---|---|---|
| UDP | SIP trunk reachable | False | N/A | N/A |
| UDP | SIP trunk not reachable | False | 4s every call | Never |
| UDP | SIP trunk not reachable | True | 4s every call |
|
| UDP | SIP trunk not reachable | True | 0s | N/A |
| TLS | SIP trunk not reachable | False | N/A | N/A |
| TLS | SIP trunk not reachable | False | 4s every call | Never |
| TLS | SIP trunk not reachable | True | 4s every call |
|
| TLS | SIP trunk not reachable | True | 0s | N/A |
Destination timeouts [#destination-timeouts-route-execution]
When setting destinations to be a SIP trunk, a PHONE number, or a WebRTC user, you can define a timeout on that destination. This parameter applies only to destinations that can be reached and functions as an answering timeout rather than a connection timeout.
As an example, consider a SIP trunk destination with a timeout set to 15 seconds:
- If the trunk cannot be reached (see SIP trunk destinations), the timeout has no effect and route execution advances to the next destination based on priorities and weights.
- If the trunk can be reached and answers to the SIP INVITE, the route execution advances after 15 seconds if the call is not answered.
Reroute calls with SIP REFER [#rerouting-with-sip-refer-route-execution]
Call Routing supports dynamic rerouting of active connected calls using the SIP REFER method. This feature is useful when you need to transfer a call to a new destination without disconnecting the original caller.
The typical flow is as follows:
- An inbound call is received on your Infobip number (Party A), triggering a predefined route in Call Routing.
- The route bridges the inbound call to an outbound call through a SIP trunk specified in the route's destination list (Party B).
- At any point during the call, instead of ending the session, the remote SIP user agent (Party B) can initiate a SIP REFER request to Infobip, specifying a new destination (Party C).
- Call Routing maintains the original inbound call and seamlessly bridges it to the newly requested destination (Party C), ensuring uninterrupted communication.
This rerouting capability allows for flexible call handling scenarios, such as transferring callers to different departments, agents, or external numbers, all while keeping the original call leg active.
- SIP REFER requests are only accepted and processed if they originate from the B party, and only when the B party is connected through SIP trunking.
- When Party B initiates a SIP REFER to transfer the call to a C party, the B party call leg will remain active even after the C party is connected. It is your responsibility to ensure your SIP user agent terminates the B party call leg when appropriate.
- If the C party rejects the call or cannot be reached, all call legs (A, B, and C) will be terminated, and the original A and B parties will not remain connected.
When Call Routing receives a SIP REFER message, it considers only routes that have a filter with the criteria type set to SIP. The To value specified in this filter must match the new destination requested in the SIP REFER.
(Optional) You may set specific SIP trunk IDs in your filter definition to further refine your execution logic.
You can flag a route as a Transfer Only Route. This ensures that the route is activated only on an incoming SIP REFER that matches the filter criteria, and not on SIP INVITE messages, even if those match the filter criteria (SIP trunk ID, to/from, or header values).
Route Simulator [#route-simulator]
The Route Simulator feature in Call Routing helps you to test which route will be selected and executed without sending live traffic.
You can simulate the following types of incoming traffic using the Route Simulator feature:
- PHONE
- SIP
- WEBRTC
Each simulated traffic type can include additional qualifying data, such as from and to values, header, custom data values. You can also choose to include disabled routes in the simulation, making it possible to test route setups without affecting live traffic.
When you add or modify routes, changes may take up to 5 minutes to become effective in simulations.
You can use the Route Simulator from the web interface and through the API.
Using the Route Simulator in the Infobip web interface:
- Go to the main screen of the Call Routing application.
- Select Simulate Route.
- Choose the type of traffic you want to simulate.
Using the Route Simulator method through the API:
To simulate route selection through the API:
- Send a POST request to the Simulate Route Selection endpoint.
- Specify inbound traffic details in the request body, including:
endpoint.type(PHONE, SIP, or WEBRTC).fromandtovalues, where applicable.- SIP trunk information and custom headers (for SIP simulations).
useDisabledRoutesto include disabled routes in the evaluation.
The simulator processes the request as if it were a real inbound call and:
- Evaluates all matching routes.
- Determines which route would be selected.
- Returns the matched criteria and the list of destinations in execution order.
Retrieve call logs [#retrieving-call-logs-route-execution]
Call logs are created for every call leg processed by Call Routing, including:
- The inbound call leg.
- Each outbound call leg that Call Routing attempts to bridge to, except for SIP trunk destinations that are in a disabled state.
Log entries for successfully bridged call legs can be matched together by a shared identical correlation identifier.
Retrieve detailed reports [#retrieving-detailed-reports-route-execution]
To retrieve detailed Call Routing reports, follow these steps:
Request a new Detailed report, which includes all details about your calls, including direction, duration and billed duration, and cost for the calls. Detailed reports also include the SIP trunk name, SIP trunk ID, correlation identifier, and dialogId.
Once downloaded, filter the Feature column on CALL_ROUTING.
For more details about using Infobip Reports, see Analyze Reports.
Access Call Routing recordings
Recordings performed by Call Routing can be accessed either through the API or on the Infobip web interface.
To find and download your Call Routing recordings from the Infobip web interface:
- Go to the recording tab under the Voice channel application.
- Select Call Routing on the sub-navigation bar.
- Expand a recording entry and review the list of related files (composed or non-composed).
- Download the available files from the Infobip cloud storage as well as their related metadata JSON file.
Call Routing recordings can be searched by route, participant type, or identity (such as username and phone number).