> ## Documentation Index > Fetch the complete documentation index at: https://docs.famulor.io/llms.txt > Use this file to discover all available pages before exploring further. # SIP troubleshooting > Diagnose outbound, inbound, and transfer failures on a BYO SIP trunk 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](/telephony/providers/fonial) and [Other and custom SIP providers](/telephony/providers/other-custom) 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](/telephony/providers/easybell#transferring-calls) for a worked example, and the [PBX & contact center guide](/telephony/providers/pbx-and-contact-center) 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](/telephony/inbound-outbound#failure-guidance) for the shared failure shape. ## Common SIP status codes | Status | Meaning | Typical cause | | --------- | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | 401 / 407 | Authentication failed | Wrong SIP username/password, or credentials changed on one side and not the other | | 403 | Forbidden | Destination not allowed by the trunk — geo-permissions, an unverified caller ID, or a source IP not on the allowlist | | 404 | Not found | The dialed DID/extension doesn't match what's configured, or the destination doesn't exist | | 405 | Method not allowed | The far end doesn't support the SIP method used. For a transfer, this almost always means the trunk doesn't support SIP REFER | | 408 | Request timeout | No answer within the ringing window | | 480 | Temporarily unavailable | Destination reachable but not currently available | | 486 / 600 | Busy | Line busy | | 487 | Request terminated | The call was cancelled before it was answered | | 503 | Service unavailable | The trunk itself rejected the request — common for a SIP REFER the provider doesn't support, or an outage on the provider's side | These map to the platform's provider-neutral failure codes (`busy`, `no_answer`, `authentication_failed`, `destination_forbidden`, `trunk_unavailable`, …) described in [Inbound & outbound calls](/telephony/inbound-outbound#failure-guidance). ## 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.