VoIP.info Troubleshooting

Sinch termination works but origination or audio fails

Trace separate Voice API applications, regional FQDNs, forwarding or callback control, customer-edge receipt, PBX routing, TLS, SDP and media without treating one working direction as proof of the other.

Reviewed 2026-10-19Current first-party Sinch Voice API SIP Trunking, callback, authentication, call-header, CDR and release-note material and retained Elastic and BYOC product-scope pages were reviewed October 19, 2026. The batch keeps the Voice API static SIP trunk path separate from Elastic and BYOC products and from Callback API control; termination toward Sinch separate from origination toward the customer; each flow's application configuration separate; regional FQDNs separate from their current address ranges; SIP signaling separate from RTP; and configured TLS or SRTP separate from observed negotiation. No Sinch account, application, key, secret, number, trunk, callback endpoint, DNS answer, certificate, PBX, firewall, packet, CDR, media stream, price, availability, compatibility, capacity or live call was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one failed call and one directional control

Record the Sinch product, application keys by role, number, timestamp and timezone, direction, region, termination result, origination result, call ID, callback result if used, customer-edge receipt, PBX response, answer and media. A working customer-to-Sinch termination call bounds one application, credential and egress path; it does not prove the separately configured origination application or its number assignment.

Redact application secrets, telephone numbers, addresses, callback bodies and call content. Do not move a credential or broaden a route before locating the earliest mismatch.

Prove the origination application and destination

For a static trunk, confirm the number is assigned to the intended origination application and preserve its SIP-forwarding URI. Resolve any {number} substitution and compare the resulting Request-URI, host, port and transport with the receiving PBX. For Callback API control, preserve the Incoming Call Event, call ID, application response and ConnectSIP destination.

An application that authenticates termination can coexist with a different application that owns origination. A callback event, forwarding rule and customer SIP route are three different observations.

Join Sinch evidence to the customer edge

Correlate the Sinch call ID, UTC timestamp and CDR result or reason with DNS, firewall and packet evidence at the customer edge. If Sinch generated no customer-facing attempt, investigate application assignment, forwarding or callback response. If an INVITE reached the edge, preserve its source, destination, transport, Request-URI, To, response and owning PBX object.

Use the current documented SIP and RTP ranges for the selected region as dated inputs. Do not pin one resolved edge or treat a successful signaling allowlist as a media rule.

Inspect loaded PBX identification and routing

For FreePBX, compare the GUI trunk and inbound route with generated PJSIP configuration and loaded endpoint, identify, context and dialplan state. For hand-managed Asterisk, compare the configured endpoint and identify sections with the running objects. Preserve the first divergence before editing.

A visible object is not proof that the process loaded it or selected it for this source. Do not enable anonymous SIP or an unrestricted catch-all route to make one attempt pass.

Separate TLS, SDP and RTP failures

If signaling uses TLS, verify the regional hostname, Let's Encrypt chain, local trust store, negotiated TLS version and cipher, then preserve the SIP dialog. Inspect the offer and answer for codec and SRTP agreement. Finally compare advertised and observed RTP endpoints and both packet directions.

Configured TLS is not a handshake; a completed SIP dialog is not decoded audio; an open media-port range is not two-way RTP. Correct the earliest demonstrated boundary, repeat the same call, verify answer and two-way audio, then restore temporary diagnostics.

Record limits and close the incident

Preserve the corrected application relationship, forwarding or callback state, PBX object, firewall revision, call ID, CDR, SIP result and media result. Note whether the change affects only new calls and whether a rollback was exercised.

The reviewed public material does not establish one universal retry matrix, failover timer, restoration interval or established-call survival result. No Sinch account, application, callback endpoint, PBX, firewall, packet, CDR, media stream or live call was inspected for this diagnostic.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.