Skip to main content
trunking lets you route calls through your own telephony provider. Configure trunks from Settings → SIP.
Not using your own carrier? Skip this page — hosted numbers work without SIP. See Create Phone Agent to get started.

Provider Compatibility

Before you configure anything in OpenCX, ask your carrier or PBX team for these exact details:
  • Confirm they can provide a standard for the call flow you want to support.
  • Confirm whether inbound and outbound calling are provisioned separately on their side. Many carriers require separate setup for each direction.
  • Ask for the , , and they expect you to use for each direction.
  • For inbound calls to OpenCX, confirm your carrier can send digest credentials. Self-serve OpenCX inbound trunks issue a generated username and password.
  • For outbound calls from OpenCX, ask whether your carrier authenticates by (username/password) or by .
  • If your carrier cannot match calls by credentials or by an IP range, ask whether it can identify them by a . See Custom SIP headers.
  • Confirm which you are allowed to present on outbound calls.
  • If they require , allowlist the OpenCX SIP IP ranges below.
  • Confirm the carrier supports at least one of the transports and codecs listed below.
If your inbound carrier only supports source IP allowlisting and cannot send SIP digest credentials, contact OpenCX before rollout. That setup is not self-serve from the dashboard today.

OpenCX SIP IP Ranges

Find the current static SIP IP ranges in Settings → SIP. Add all listed ranges to your carrier allowlist when the carrier authenticates outbound calls from OpenCX by source IP.

Supported Transports And Codecs

For carrier setup, use:
  • Transports: UDP, TCP, or TLS.
  • Codecs: G.711 μ-law (PCMU), G.711 A-law (PCMA), or G.722.
OpenCX handles SIP codec negotiation automatically.

Provider Guides

Some provider-owned guides that are useful when configuring a provider to route calls to an external SIP endpoint:

Inbound SIP Trunks

Route calls from your carrier to OpenCX agents. Inbound trunks are configured entirely on our side from Settings → SIP. What OpenCX provides:
  • A SIP endpoint in the region you choose: Global (auto-route), US, EU, United Kingdom, India, Japan, Australia, or Saudi Arabia.
  • Generated digest credentials (username and password) for your carrier or to send calls to OpenCX.
  • Routing by the dialed number or by the header.
What we need from your carrier:
  • One or more verified BYOC phone numbers that match the DIDs your carrier sends in the . You can also contact us to manually add verified numbers.
  • A trunk on the carrier or PBX side that points to the OpenCX SIP endpoint using the generated credentials.

Outbound SIP Trunks

Make outbound calls from OpenCX through your carrier. Outbound trunks are configured on our side from Settings → SIP. What OpenCX supports:
  • : UDP (default), TCP, or TLS.
  • Authentication by (username/password) or by .
  • Custom SIP headers sent with every call placed through the trunk.
  • A number format per trunk, so the dialed number and caller ID are written the way your carrier routes them.
What we need from your carrier:
  • The outbound SIP host and port.
  • The caller ID number approved for outbound presentation.
  • The outbound authentication method: digest username/password, or source IP allowlisting. For IP allowlisting, add the OpenCX SIP IP ranges (found in Settings → SIP) to the carrier-side rule.
  • Any header name and value the carrier expects on each call, if it identifies your traffic that way.
  • The number format the carrier expects, for example with or without a leading +.

Number format

Carriers differ on how they expect phone numbers to be written, and usually reject a call in another format as not found. Set Number format on the outbound trunk to match your carrier: The format applies to the dialed number and the caller ID on every call through the trunk, including calls placed by teammates, and to Test connection. Sessions, contacts, and webhooks keep the number as it was entered. Only numbers saved with a leading + or 00 are rewritten. Anything else, such as bare digits, local numbers, or short extensions, is sent unchanged, so save contact numbers in international form with a + for the format to apply.

SIP Transfer Destinations

Route call transfers through SIP instead of the public phone network. Transfer destinations are managed at the organization level and then assigned to agents.
  • Phone destinations transfer to an E.164 phone number.
  • SIP destinations transfer to a SIP URI such as sip:[email protected]. Optional (username/password) is supported for SIP endpoints.
  • Custom destinations end the call and are useful when workflows handle pre-transfer or post-transfer behavior.
SIP destinations can also send custom SIP headers with every transferred call. A Classical IVR can connect a caller to a SIP destination and take them back afterwards; see Transfers to a SIP destination.

Caller ID, encryption and allowed headers

Edit the destination in Settings → SIP to match what the endpoint requires:
  • Always send the caller’s number: the endpoint receives the caller’s own number as From on every transfer, and callers who hide their number are sent as anonymous. OpenCX never falls back to your organization’s number, even if the endpoint rejects the caller’s. It cannot be combined with a fixed Caller ID.
  • Transport: the protocol used for the endpoint’s signalling. Choose TLS for endpoints that require encrypted signalling, usually on port 5061.
  • Encrypt call audio (SRTP): When the endpoint supports it encrypts audio whenever the endpoint offers it; Always fails the transfer when the endpoint cannot encrypt. Pair it with TLS.
  • Send only allowed headers: the endpoint receives only the header names you list, matched without regard to letter case. The list covers the destination’s custom headers, the headers IVR transfer steps set, and the identifiers OpenCX adds to transfers. Add X-OPENCX-SESSION-ID when the endpoint hands calls back. An empty list sends no custom headers. Custom headers missing from the list are flagged in the form and are not sent.
Test connection uses the transport, encryption and allowed headers currently in the form. Saving a change to any of them, or to the destination’s address, credentials or custom headers, rebuilds the destination’s connection with all of its current settings; the next transfer uses them. Transfers never change the connection themselves: a destination saved before Transport applied to transfers keeps its existing connection until you save one of these settings.

Custom SIP headers

Add custom SIP headers to an outbound trunk or a SIP transfer destination when the other side needs more than credentials or an IP allowlist to recognize your calls. A common case is a carrier that matches calls to your account by a shared key in a header, because it cannot match on a range of source IPs. To add one, open Settings → SIP, create or edit the outbound trunk or SIP transfer destination, and use Custom SIP headers → Add header. You need permission to edit voice channel settings.
  • Headers set on an outbound trunk are sent on every call placed through that trunk.
  • Headers set on a SIP transfer destination are sent on every call transferred to that destination.
  • Test connection sends the headers currently in the form, so you can confirm the carrier accepts them before saving.
Rules for headers:
  • The name must start with X- and use only letters, digits, ., _, or -, for example X-Customer-Key.
  • Names starting with X-OPENCX- are reserved for the headers OpenCX adds to each call.
  • The value can be up to 255 printable ASCII characters.
  • You can add up to 20 headers per trunk or destination.
Header values are stored encrypted and hidden after you save. When you edit a trunk or destination, leave a value blank to keep it, type a new value to replace it, or remove the header to stop sending it. Treat a shared key like a password and send it to your carrier over a secure channel.
Saved values are only reused for the host they were saved with. If you change the SIP host, enter each header value again before you save or run Test connection. Changing only the port, transport, or extension keeps them. If two people edit the same trunk or destination at once, the second save is rejected so it cannot undo the first. Reload the page and apply the change again. On a transferred call, a header set on the destination always takes precedence over a header with the same name that arrived on the original call. If calls are rejected after you add a header, confirm the exact header name and value with your carrier, including letter case, and check that the carrier reads it from the initial call request (the SIP INVITE).

Advanced: Dynamic Agent Routing

For advanced setups, use the SIP header to route inbound calls to a specific agent dynamically. Include the agent’s ID (shown on the agent settings page) in the header when sending calls to the OpenCX SIP endpoint. This is useful when:
  • Multiple agents share the same trunk
  • Your or carrier decides which agent should answer based on logic or caller data

Supported SIP Headers

OpenCX forwards SIP X-* headers from inbound calls. These headers have first-class behavior:
  • X-OPENCX-AGENT-ID: route the call to a specific phone agent.
  • X-OPENCX-CONTACT-ID: attach the call to an existing OpenCX contact in the same organization. If the contact is missing or belongs to another organization, OpenCX falls back to phone-number matching.
  • X-OPENCX-CONTACT-CUSTOM-DATA: JSON object merged into the contact. Values must be strings, numbers, or booleans.
  • X-OPENCX-SESSION-CUSTOM-DATA: JSON object merged into the call session. Values must be strings, numbers, or booleans.
  • X-OPENCX-AGENT-LANGUAGE: override the agent language for this call. Use one ISO code or a comma-separated list supported by the phone agent language settings.
  • X-OPENCX-INCLUDE-INSTRUCTION-IDS: comma-separated instruction IDs to include for this call.
Other X-* SIP headers are stored on the session with the leading X- prefix removed.

Create Phone Agent

Set up an agent to receive SIP-routed calls.

Agent Configuration

Assign trunks and numbers under Telephony & Routing.

Outbound Calls

Launch calls from the dashboard, API, or workflows.

Validate the complete route

Test inbound calling, outbound calling, and transfers separately. A successful inbound call does not validate outbound credentials or caller identity. Confirm the dialed number is assigned to the intended agent, or send an explicit X-OPENCX-AGENT-ID header. See Numbers and routing for routing precedence and human-answering behavior. For no-ring, rejected-call, or audio failures, use Phone troubleshooting. Keep the exact call time and timezone, caller and destination numbers, session link if created, and your carrier’s result for the same attempt.