Sinch Voice API SIP trunking: application, regional edge and media evidence

Name the current product and control path

The current Voice API reference documents a static SIP trunk and a Callback API path. A static trunk can contain termination toward Sinch, origination from Sinch, or both. The callback path instead lets an application respond to an Incoming Call Event and use a ConnectSIP action. Record the application, path, direction and owner before diagnosing credentials or routing.

Do not import an older Elastic SIP Trunking endpoint model into this Voice API path without current account evidence. A dashboard label, application key, forwarding URI and callback URL belong to different controls.

Configure termination and origination as separate flows

Sinch defines termination as the customer SIP infrastructure sending a call toward Sinch. It requires a regional termination FQDN, application key as authentication name, application secret and a matching regional realm. The called number must be E.164-formatted, and the asserted caller identity must be a Sinch DID on the account or a number verified in the portal.

Origination is Sinch sending a call toward the customer SIP infrastructure. Static configuration uses SIP forwarding and a valid SIP URI; {number} can be replaced by the inbound number. The reference says static trunks use one application for termination and another application for origination, with numbers assigned to the origination application. One successful direction does not prove the other application.

Resolve regional FQDNs without pinning one edge

The current reference publishes separate Europe, North America, South America, Southeast Asia and Australia termination FQDNs and says each resolves to several public edges across Availability Zones. Preserve the configured region, DNS answers, selected address, transport and response. Use the FQDN rather than a proxy address unless Sinch support supplies another design.

The page also publishes current SIP signaling and RTP ranges. Treat those as dated service documentation, not a timeless copied firewall object. Reconcile the live page, ordered region and change record before editing network policy.

Separate callback control from SIP forwarding

With SIP forwarding, the origination application carries the destination URI. With callback control, Sinch sends an Incoming Call Event to the configured backend and expects a valid response; the callback reference says a missing response within its timeout produces an error and disconnects the call. Preserve the call ID, UTC timestamp, application key, inbound number, callback request, application response and resulting SIP leg.

A callback receipt is not a SIP INVITE at the customer edge, and a generated SIP INVITE is not proof that the PBX identified, routed or answered it. Custom call headers can support correlation, but they can contain customer data and have documented size limits; retain only authorized, redacted evidence.

Prove signaling and media independently

Sinch documents UDP and TCP for termination and SIP forwarding URIs that can select UDP, TCP or TLS. Its secure-trunk section recommends TLS 1.2, lists cipher suites, identifies Let's Encrypt certificate trust requirements and says SRTP is offered and accepted when TLS carries signaling. Verify hostname, chain, trust store, handshake, SIP transport, SDP crypto, RTP endpoints and both media directions.

The current page lists G.711u, G.711a, Opus and G.729, SIP ports 5060 and 5061, and regional media ranges with UDP ports 10000 through 60000. Those documented values do not prove one PBX negotiated a codec, accepted SRTP or received media.

Correlate one bounded acceptance trace

For one authorized number and time window, record product, applications, direction, region, DNS answers, source and destination, transport, call ID, CDR result, callback event if used, customer-edge receipt, PBX response, answer, SDP and both media directions. Sinch CDRs expose a call identifier, call time, result, reason, duration, identities, application key and other fields; preserve only the minimum redacted evidence needed.

Confirm current number eligibility, portability, emergency workflow, messaging, fax, DTMF, codec availability, capacity, call-start rate, pricing and support for the exact account. Use the paired diagnostic for a directional failure.

Diagnose a directional Sinch Voice API failure

Use the Sinch directional diagnostic to join application ownership, regional routing, forwarding or callback control, PBX handling and media.