Skip to main content
Work through outbound first, then inbound. Outbound isolates credentials, transport, and codecs before call-routing variables (FQDN, source IPs, DID matching) enter the picture, and most trunks get outbound working in minutes.

​
The platform never sends SIP REGISTER

The platform authenticates every call directly, per request — it never registers to your provider, and it never expects your provider to register to it. If your provider’s dashboard shows the trunk or SIP user as Offline / Not registered after setup, that’s expected, not a fault: inbound calls arrive over the destination you configured (the platform SIP FQDN), not over a registration. Several provider guides call this out explicitly because it looks broken at first glance — see Fonial and Other and custom SIP providers for examples.

​
Outbound calls don’t connect

  1. Re-check the termination host, transport (UDP/TCP/TLS), and credentials against the provider’s own documentation first — a mismatched transport, or a stray sip: prefix or port on the termination address, is the most common cause.
  2. Confirm the outbound calling number format (international with +, international without +, or national) matches what the provider expects for that trunk — the wrong format is silently rejected by some carriers and accepted-then-dropped by others.
  3. If the provider requires calls from a single, whitelisted source IP, enable Fixed outbound IP explicitly. The platform has no static outbound IP otherwise, so a provider-side IP allowlist without that toggle fails every call.
  4. Compare codecs: a provider that only accepts G.711 will reject, or deliver one-way audio on, a call still offering Opus/G.722.
  5. Change one setting at a time and place a single test call after each — History shows the exact SIP status code, which narrows the cause far faster than guessing.

​
Inbound calls don’t reach the assistant

  • Send to the platform’s SIP FQDN, never to a raw IP address. Sending to an IP is the single most common inbound failure, and it fails silently on both sides — no call ever reaches History.
  • With Provider source IPs, every current signaling IP/CIDR must be entered. A stale or incomplete list drops calls without a clear error; it doesn’t reject them loudly.
  • Confirm the DID matches exactly what the provider sends — a SIP Extension trunk also needs its Primary DID set, since it isn’t a wildcard.
  • If nothing arrives in History at all (not even a failed call), the provider isn’t reaching the platform yet — check its own outbound/forwarding rule before assuming a platform-side auth issue.

​
Call transfers fail (SIP REFER)

A cold or warm transfer that fails while ordinary calls work fine almost always comes down to one of these, in order:
  1. The trunk doesn’t support SIP REFER. Not every carrier accepts it — see the Easybell guide for a worked example, and the PBX & contact center guide for Aircall/Five9-specific notes. When this is the cause, no destination-format change fixes it: switch that transfer to Warm Transfer, which places a fresh outbound call and bridges it instead of REFER-ing the existing call.
  2. The SIP URI format. If REFER is supported but still fails, try the variants in order: with the port (sip:+1234567890@sip-server:5060), without the port, then a bare sip:+1234567890.
  3. The destination itself. Confirm the target number is reachable and not blocked before assuming the trunk is at fault.
Every attempted transfer — successful or not — leaves call_transfer_failed or warm_transfer_failed in the call’s event log; see Inbound & outbound calls for the shared failure shape.

​
Common SIP status codes

These map to the platform’s provider-neutral failure codes (busy, no_answer, authentication_failed, destination_forbidden, trunk_unavailable, …) described in Inbound & outbound calls.

​
General connectivity

  • Confirm the network the trunk runs behind has a working internet connection.
  • Confirm no firewall blocks outbound SIP traffic — a firewall that only opens standard ports (5060/5061) silently drops providers using non-standard signaling ports (for example Genesys Cloud’s 32681/32682).

​
Before contacting support

  • Outbound: credentials verified, correct trunk/phone type selected, Fixed outbound IP configured if the provider requires it, one direct test call placed.
  • Inbound: authentication method configured (source IPs or username/password), every current provider IP entered if using IP auth, provider confirmed to send to the FQDN (not an IP), one test call placed from an external number.
  • General: network connectivity confirmed, firewall ruled out.

​
Getting help

Include, when you contact support:
  • The call ID from History.
  • The exact trunk configuration (type, transport, auth method).
  • Test results for both directions (outbound and inbound).
  • For transfer issues, the exact SIP URI format you tried.
Test inbound and outbound independently — one working never confirms the other.