Freeze the trunk, number and route objects independently
Infobip documents static, registered and specialized authenticated SIP trunks with different source-address, REGISTER, credential and transport behavior. Preserve the exact trunk ID and type, administrative state, data centre or region, customer destinations, ordered channels, number or inbound source, assigned route and configuration owner before changing any one object.
A registered trunk state does not prove that a number selects a route, that a route contains that trunk, or that a call reaches the customer edge. A static trunk does not need a registration binding. Keep the account record, API response, route definition, SIP exchange and PBX result as separate evidence.
Documented service facts
Reviewed 2026-10-20. Compare SIP trunk services →
Authentication
DocumentedInfobip documents static trunks authenticated by declared public dedicated source IPs and registered trunks authenticated by username and password. A separate authenticated-trunk type uses DIGEST credentials and an X-IB-AccessCode header for selected external platforms. Record the ordered trunk type and credential owner; these models are not interchangeable.
SIP registration
DocumentedRegistered trunks use a PBX or SBC registration and expose REGISTERED or UNREGISTERED status; static trunks use configured addresses instead. Infobip says disabling a registered trunk forces deregistration. Preserve administrative, registration and action status separately rather than treating one green state as call readiness.
Inbound delivery
DocumentedInfobip documents renting a Voice number, assigning an inbound route and forwarding it through Call Routing to a selected SIP trunk. A static trunk also requires at least one customer destination IP or FQDN. Keep the number, route, destination order and delivered identity distinct from outbound trunk authentication.
Inbound failover
DocumentedInfobip Call Routing can try one to ten destinations in priority order, distribute entries at the same priority by weight and skip entries that are ineligible, Administrative Down or already out of service through OPTIONS polling. Connection behavior and the reachable-destination answer timeout remain separate. Preserve every route entry and per-leg result.
Number and regional availability
Not verifiedInfobip describes outbound reach across more than 200 countries and self-service SIP acceptance in geographically dispersed data centres, while its Numbers service filters inventory by country and channel capability. Exact number stock, portability, documents, caller-ID rights and activation remain specific to country, number, account and date.
Audio codecs
DocumentedThe trunk reference lists PCMA, PCMU and G.729 plus RFC 2833 and in-band DTMF. A configured option is not proof of end-to-end negotiation, transcoding quality or destination support. Preserve the offer, answer, RTP payloads and DTMF result for every required call path.
T.38 fax
DocumentedInfobip lists T.38 and in-band fax modes and requires fax transcoding choices in trunk configuration. That establishes selectable platform support, not route, carrier, gateway or document success. Qualify the exact number and direction with approved page profiles and retained evidence.
Signaling and media encryption
DocumentedInfobip documents UDP and a TLS/SRTP option for PBX-to-platform signaling and media; its authenticated-trunk type supports only TLS connectivity. Confirm which trunk type, port, certificate-validation behavior, SRTP profile and downgrade policy the account uses. Protection on this leg is not an end-to-end PSTN guarantee.
Concurrent calls and call starts
Not verifiedInfobip defines one channel as one concurrent inbound or outbound call and says the default setup allows up to 1,000 channels per trunk, subject to the ordered plan and account. The reviewed public pages do not establish a calls-per-second or burst limit. Obtain active-call and call-start controls separately before any authorized load test.
Emergency calling
Not verifiedThe reviewed setup page requires a service address for US trunks but describes it as a taxation and regulatory location for the service, not as an emergency-calling activation procedure. No trunk emergency-routing, validated-dispatchable-location, callback or approved test workflow was verified. Confirm these items for every service location before relying on emergency calls.
Pricing model
DocumentedInfobip documents metered and US unlimited channel plans. Metered service combines a channel charge with usage-rated traffic; the US unlimited plan excludes usage charges for domestic outbound traffic subject to fair use, while inbound and other-country traffic remain usage-rated. Capture the current quote, channel quantity, destination rates, numbers, taxes and fair-use terms.
Administration and support
DocumentedInfobip documents portal and API trunk management, Route Simulator selection without live traffic, route-change propagation of up to five minutes, per-leg call logs and detailed reports with trunk, correlation and dialog identifiers. These records do not establish PBX receipt, media, incident SLA or support response.
SMS
Not verifiedInfobip Numbers can support SMS, MMS or Voice depending on the exact number, and messaging uses separate APIs, sender registration, routing and compliance controls. A voice-capable DID or SIP trunk does not establish SMS enablement. Verify number capability, sender approval, consent, throughput, inbound handling and fees independently.
Resolve route selection before destination execution
Call Routing can use a route statically assigned to an Infobip number or select a route through filters on inbound PHONE, SIP or other supported traffic. Multiple filters on one route use OR logic, while paired from and to fields inside one PHONE filter use AND logic. Preserve the actual inbound type, from, to, relevant headers, number action, route priority and matched filter.
The Route Simulator evaluates selection without sending live traffic and can optionally include disabled routes. Treat its result as configuration-path evidence, not proof of trunk reachability, PBX acceptance, media or a completed call. Infobip notes that newly added or modified routes can take up to five minutes to propagate into system caches and simulations.
Read destination priority, weight and eligibility in order
A route can contain one to ten destinations. Priority from 1 to 100 defines the hunt sequence; weight divides traffic among entries sharing a priority. Allowed Time Windows can make a destination ineligible at execution time. Preserve every entry, its type, priority, weight, time window, enabled state, optional username rewrite and timeout.
A lower-priority entry receiving a call is not by itself proof that the preceding SIP trunk failed. The earlier entry may have been disabled, administratively down, outside its time window, considered out of service, unreachable, unanswered or rejected under the route engine's advancing conditions.
Keep OPTIONS service state apart from per-call reachability
Infobip says a SIP destination is skipped immediately when it is Administrative Down or considered out of service by enabled OPTIONS polling. Without OPTIONS, an unreachable UDP or TLS trunk can incur the documented per-call connection delay and is never placed out of service by that mechanism. With OPTIONS, the first failed period can still include protocol timers before later calls skip the destination immediately.
Record transport, administrative state, whether OPTIONS is enabled, the last poll evidence, the time service state changed, the attempted call's timestamps and the selected next entry. Do not infer a successful INVITE, REGISTER, call or media path from one OPTIONS response.
Treat the destination timeout as an answer timer
Infobip documents the destination timeout as applying only after a destination is reachable; it functions as an answering timeout, not a connection timeout. A reachable SIP trunk that receives the INVITE but does not answer can advance when this timer expires, while an unreachable trunk follows the separate reachability behavior.
Measure DNS, socket establishment, first SIP response, provisional progress, answer and route advance independently. Raising the answer timeout cannot repair a failed connection, and lowering it can move valid slow-answer calls to another destination. Preserve the customer PBX response before changing the route timer.
Correlate one route decision with every call leg
Infobip says Call Routing produces a log for the inbound leg and each outbound leg it attempts, except a SIP-trunk destination already in a disabled state. Successfully bridged legs can share a correlation identifier; detailed reports can include the trunk name, trunk ID, correlation identifier and dialog ID. Preserve those fields with UTC timestamps, SIP Call-ID where available and customer-edge evidence.
A missing outbound leg can mean the destination was disabled or never reached in execution order; it is not universal proof that the provider lost the call. A bridged log or report row does not prove intelligible two-way audio. Correlate the selected route, leg sequence, SIP responses, SDP, RTP directions and an authorized endpoint observation. No Infobip service behavior was laboratory validated for this guide.
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 ↗
- Infobip Voice number setup ↗
- Infobip Numbers ↗
- Infobip number types ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.