This page is the troubleshooting companion to the SIP Trunking (BYO SIP Trunk Integration) setup page. Where that page covers how to configure a SIP trunk credential and register a number against it, this page covers what to check when inbound or outbound calls over that trunk aren't working — common gateway misconfigurations, the full gateway field reference, and how to read SIP response codes returned during call setup.
One of the most common BYO SIP trunk failures is using a hostname instead of a numeric IP address for an inbound gateway. Hostnames are only supported for outbound gateways. For inbound traffic, the gateway's ip field must be a numeric IPv4 address so the system can match incoming SIP requests against it — a hostname cannot be resolved and matched the same way at the point an inbound call arrives.
If your gateway configuration used a hostname (e.g. sip.yourprovider.com) and inbound calls are failing or being rejected, switch the ip field to your provider's numeric IPv4 address and confirm it matches what your carrier actually sends from.
The inboundEnabled field on a gateway defaults to true. If you're setting up a trunk that should only be used for outbound calls, leaving this at its default can cause unexpected inbound call attempts to be routed to a gateway that isn't set up to properly validate or handle them, which can surface as authentication or routing failures.
For an outbound-only trunk, explicitly set inboundEnabled: false on the gateway:
{
"ip": "YOUR_PROVIDER_IP",
"inboundEnabled": false,
"outboundEnabled": true
}Don't assume a gateway is outbound-only just because you only configured outbound routing elsewhere — check this field explicitly on every gateway in the trunk.
Before calls will flow, your carrier needs to allowlist the platform's signaling IP addresses for your region. Missing any of these IPs will prevent proper whitelisting and typically shows up as a 401 Unauthorized on inbound calls.
| Region | SIP Host | Signaling IP Addresses | RTP Media |
|---|---|---|---|
| US | sip.sulus.ai | 44.229.228.186/32, 44.238.177.138/32 | Dynamic IPs; UDP ports 40000–60000 |
| EU | sip.eu.sulus.ai | 63.182.83.170/32 | Static IP 63.182.83.170; UDP ports 40000–60000 |
Provide all signaling IP addresses for your region when allowlisting — a partial allowlist is a common source of intermittent inbound failures.
Each entry in a SIP trunk credential's gateways array supports the following fields:
| Field | Type | Default | Description |
|---|---|---|---|
ip | string | required | IPv4 address or hostname. Hostnames only work for outbound gateways — inbound requires a numeric IP. |
port | number | 5060 | SIP signaling port. |
netmask | number | 32 | Subnet mask for inbound IP matching (valid range: 24–32). |
inboundEnabled | boolean | true | Whether this gateway accepts inbound calls. |
outboundEnabled | boolean | true | Whether outbound calls route through this gateway. |
outboundProtocol | string | "udp" | Signaling protocol: udp, tcp, tls, or tls/srtp. |
optionsPingEnabled | boolean | false | Send SIP OPTIONS pings to check gateway reachability. |
Before diving into a specific code, gather context from your dashboard under Observe > Logs > Calls: the call ID, timestamp, call direction, the endedReason field, and which system in the path actually returned the response (the platform, your provider, or a downstream carrier). The same code can have different causes depending on which system returned it.
| Code | Meaning | What to Check |
|---|---|---|
401 Unauthorized | Authentication is being requested — often a normal digest-auth challenge | SIP username/password, authentication realm, and whether an authenticated request followed the challenge |
403 Forbidden | Request understood but refused — an authorization/policy rejection, not just a missing credential | Credentials, caller ID and destination permissions, geographic restrictions, trunk/account limits; for outbound, confirm your provider allows the signaling IPs above; for inbound, confirm the provider's source IPs match your configured gateways |
407 Proxy Authentication Required | A SIP proxy (not the destination) is requesting authentication | Trunk username/password, authentication realm, proxy configuration, and whether an authenticated request followed |
408 Request Timeout | The responding server didn't reply in time | DNS resolution, firewall rules, signaling ports, transport protocol (UDP/TCP/TLS), and endpoint availability |
503 Service Unavailable | Server temporarily unavailable — providers also use this for routing failures or call limits, not just outages | Provider status pages, account/trunk capacity and limits, any Retry-After header, and whether an alternate route or failover is available |
Note: a 4xx response does not necessarily mean your request was invalid — providers use 4xx codes for account restrictions, routing rules, and destination state as well. Don't retry blindly on a 403 without identifying the specific restriction first.
If the issue persists, gather the call ID, timestamp with timezone, call direction, exact SIP response code and reason phrase, and a redacted signaling trace before contacting your carrier or support — never include SIP passwords or API keys in logs you share.
Read-only access to this documentation from your AI tools. No login, OAuth, or token required — just the endpoint below.
https://docs.sulus.ai/mcp/sulus-docs-public
Settings → Connectors.Add custom connector.Sulus Docs and paste the endpoint above as the Remote MCP server URL.Add, then enable it in your chat.Settings → Connectors.Developer mode (Settings → Connectors → Advanced) if you don't see custom connectors.Create / Add custom connector and paste the endpoint above as the MCP Server URL.No authentication and create the connector.Custom MCP connectors require a ChatGPT plan with developer mode / connectors enabled.