> For the complete documentation index, see [llms.txt](https://docs.dapta.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dapta.ai/ai-voice-agents/phone-numbers/connecting-your-sip-trunk/connect-your-own-sip-trunk-custom-byo.md). # Connect your own SIP trunk (custom / BYO) Connect your own Twilio Elastic SIP Trunking setup, carrier, PBX, or SIP trunk to Dapta for outbound and inbound Voice Agent calls. Use a custom SIP trunk when your company already has Twilio Elastic SIP Trunking, another SIP carrier, a PBX, a contact center, or phone number routing that Dapta should use. Your telephony admin provides the trunk details, and Dapta uses that trunk for inbound calls, outbound calls, or both. *** ## Before you begin You need access to the team that manages your carrier or PBX. Do not send credentials in a public channel; share them only through the secure process provided by Dapta Support or your implementation contact. {% hint style="danger" %} **Your SIP trunk must be private. This is mandatory.** Never leave a trunk open to the public internet: an open trunk lets anyone place calls through your carrier account. Every BYO trunk connected to Dapta must have both protections: * **SIP authentication** - a username and password on the trunk. * **IP allowlisting** - allow all of [Dapta's IPs](#dapta-ips-to-allow) and block every other source. {% endhint %} {% hint style="warning" %} Some carriers only allow outbound calls from a caller ID that is already registered with them. Confirm the allowed caller IDs before you test outbound calls. {% endhint %} *** ## Dapta IPs to allow Allow **every** IP and range in this table on your carrier, PBX, SBC, or firewall, for SIP signaling (port `5060`) and RTP media. Do not leave any out: if one is missing, some calls work and others fail, for example inbound calls connect but transfers time out. | IP or range | Used for | | ------------------ | --------------------------------------------------------------------- | | `3.135.117.63` | Dapta servers: webhooks, API requests, Flow Studio, voice agent tools | | `3.14.139.223` | Dapta servers: database connections and AI services | | `143.223.88.0/21` | Voice calls (SIP and audio) | | `161.115.160.0/19` | Voice calls (SIP and audio) | | `153.57.128.0/18` | Voice calls (SIP and audio) | *** ## Common BYO SIP trunk scenarios | Scenario | Use this section | | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | Your company owns the Twilio account or Twilio phone numbers | [Twilio Elastic SIP Trunking example](#twilio-elastic-sip-trunking-example) | | Your company uses another SIP carrier, PBX, SBC, or contact center | [Other SIP trunks and PBX providers](#other-sip-trunks-and-pbx-providers) | | You need dedicated routing, SIP proxy behavior, human queue transfer, or higher concurrency | [Enterprise custom telephony](/ai-voice-agents/phone-numbers/connecting-your-sip-trunk/custom-telephony-for-enterprise-large-companies.md) | {% hint style="info" %} In this guide, "Twilio" means your own Twilio account. It is not the same as a Dapta-managed number purchased inside Dapta. {% endhint %} *** ## Step 1 - Gather your trunk credentials Ask your carrier or PBX admin for: 1. **SIP host / domain** and **port** - for example, `` and port `5060`. 2. **SIP auth username** and **SIP auth password**. 3. The **DID(s)** or **extension** Dapta should use. 4. Which **caller IDs** the carrier will present and accept. 5. Whether the trunk should support **outbound**, **inbound**, or both. 6. The number of **concurrent channels** your carrier has provisioned. Then ask them to allowlist all of [Dapta's IPs](#dapta-ips-to-allow) on the carrier, PBX, or firewall. This is mandatory for every BYO trunk. If your provider needs additional IPs or ranges for your setup, [contact Dapta Support](https://calendly.com/dapta-support/support-30). *** ## Twilio Elastic SIP Trunking example Use this section when you want Dapta to place or receive calls through your own Twilio account. ### Twilio terms to map into Dapta | Twilio term | What it means for the Dapta setup | | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Termination** | Outbound calls from Dapta to Twilio, then from Twilio to the public phone network. | | **Termination SIP URI / Domain Name** | The Twilio SIP domain Dapta should dial, usually ending in `pstn.twilio.com`. | | **Credential List** | SIP username and password that Dapta can use to authenticate outbound calls to Twilio. | | **IP Access Control List** | Twilio allowlist for all of [Dapta's IPs](#dapta-ips-to-allow), in addition to username/password authentication. | | **Origination** | Inbound calls from a Twilio number to Dapta. | | **Origination SIP URI** | The Dapta-provided SIP URI where Twilio should send inbound calls. | | **Phone Numbers** | Twilio numbers associated with the trunk for inbound routing. | ### For outbound calls through Twilio Ask your Twilio admin to: 1. Create or open an **Elastic SIP Trunk** in Twilio. 2. Configure **Termination** for that trunk. 3. Share the trunk's **Termination SIP URI** with Dapta, such as `.pstn.twilio.com`. 4. Create a **Credential List** for Dapta and allow all of [Dapta's IPs](#dapta-ips-to-allow) in Twilio's **IP Access Control List**. If both are configured in Twilio, both must match. 5. Confirm which caller IDs Twilio will accept for outbound calls. Twilio commonly requires the caller ID to be a Twilio number in the account or a verified caller ID. 6. Confirm that outbound destination numbers will be sent in full E.164 format with the leading `+`, such as `+15555550123`. 7. Confirm whether your team enabled Twilio **Secure Trunking**. If they did, coordinate TLS/SRTP requirements with Dapta before testing. Then configure the Dapta SIP trunk using: | Dapta field | Twilio value | | --------------------- | ------------------------------------------------------------------------------------------------------------------ | | **Name** | A clear label, such as `Main Twilio trunk`. | | **SIP host / domain** | The Twilio termination domain, such as `.pstn.twilio.com`. | | **Port** | The port provided by your Twilio setup. Use `5060` unless your Twilio or security setup requires a different port. | | **Auth username** | The SIP username from the Twilio Credential List. | | **Auth password** | The SIP password from the Twilio Credential List. | | **DID / Extension** | The Twilio number or caller ID Dapta should use, if required by the workspace setup. | | **Dial Pattern** | **ISO / with country code** so numbers are sent in E.164 format with the `+` prefix. | {% hint style="warning" %} Do not paste Twilio Auth Tokens, SIP passwords, or production phone numbers into public tickets or shared docs. Use the secure process provided by Dapta Support or your implementation contact. {% endhint %} ### For inbound calls from Twilio to Dapta Ask Dapta Support or your implementation contact for the SIP URI Twilio should use for inbound calls. Then ask your Twilio admin to: 1. Configure **Origination** on the Twilio trunk. 2. Set the **Origination SIP URI** to the Dapta-provided SIP URI. 3. Associate the Twilio phone number with the trunk. 4. Confirm Twilio can reach the Dapta SIP URI from the selected Twilio edge or region. 5. Route one test Twilio number first before moving production numbers. After the Twilio side is ready, choose the **Inbound Agent** in Dapta and save the SIP trunk. {% hint style="info" %} For a Twilio setup that you own, Dapta needs the SIP trunk connection details. Dapta does not need access to your full Twilio account unless your implementation process explicitly requires it. {% endhint %} *** ## Other SIP trunks and PBX providers Use this section for carriers, PBXs, SBCs, and contact centers that are not Twilio. Ask your telephony admin to provide the same core information: | Requirement | Examples | | ------------------------ | ----------------------------------------------------------------------------------------- | | SIP endpoint | Carrier domain, PBX domain, SBC FQDN, or public IP. | | Authentication | SIP username/password, plus IP allowlisting of all of [Dapta's IPs](#dapta-ips-to-allow). | | Number format | E.164 with `+`, E.164 without `+`, national format, or extension format. | | Caller ID policy | Which DIDs or caller IDs the provider accepts for outbound calls. | | Inbound routing | Which DID, extension, or route should reach the Dapta Voice Agent. | | Media and firewall rules | RTP ports, SIP signaling IPs, and any NAT/SBC requirements. | | Capacity | Concurrent channels and calls-per-second limits. | Make sure the provider allows all of [Dapta's IPs](#dapta-ips-to-allow) and keeps the trunk closed to every other source. If your setup needs additional IPs or ranges, [contact Dapta Support](https://calendly.com/dapta-support/support-30). If the provider uses your SBC or PBX, confirm that the SBC or PBX does not rewrite SIP headers or SDP in a way that breaks routing or audio. If audio is one-way or calls drop after connecting, ask the telephony admin to review NAT, RTP, codec, and firewall behavior. *** ## Step 2 - Configure outbound calling Outbound calling means Dapta dials out through your trunk. In Dapta, go to **Voice Agents > SIP Trunks** and click **New Sip Trunk Extension**.
Dapta Sip Trunks page showing the search field, New Sip Trunk Extension button, and trunk table columns

Use the Sip Trunks page to add and manage SIP trunk extensions for Voice Agents.

Fill in the trunk fields using generic carrier values: | Field | What to enter | | --------------------- | -------------------------------------------------------------- | | **Name** | A clear label, such as `Main SIP trunk`. | | **SIP host / domain** | Your carrier or PBX host, such as `your-carrier.example.com`. | | **Port** | Usually `5060`, unless your carrier gave you a different port. | | **Auth username** | The SIP username from your carrier or PBX. | | **Auth password** | The SIP password from your carrier or PBX. | | **DID / Extension** | The number or extension Dapta should use for this trunk. | In the trunk settings, set **Dial Pattern** to match what your carrier expects. | Dial Pattern | Use it when... | Number format | | -------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------ | | **ISO / with country code** | Your carrier expects the full international number. | Full E.164, such as `+15555550123`. | | **Local / without country code** | Your carrier expects local numbers and a separate country code. | Local number plus the **Country Code** field in Dapta. | Before testing outbound calls, confirm: * The **caller ID** Dapta presents is registered or accepted by your carrier. * Your carrier accepts the number format Dapta sends. * Some carriers require the leading `+` in E.164 numbers, for example `+15555550123`. * The provider's firewall or access control allows all of [Dapta's IPs](#dapta-ips-to-allow). {% hint style="warning" %} If outbound calls fail at the carrier, check the dial pattern and the `+` prefix first. A number that works as `+15555550123` may fail if the carrier receives `15555550123`. {% endhint %} *** ## Step 3 - Configure inbound calling Inbound calling means calls to your DID or extension reach a Dapta Voice Agent. In the trunk settings, choose the **Inbound Agent** that should answer calls for this trunk or extension, then save the trunk. On your carrier or PBX side, route the DID or extension to Dapta using the trunk configuration, and make sure all of [Dapta's IPs](#dapta-ips-to-allow) are allowed. *** ## Step 4 - Test both call directions Test outbound first, then inbound: 1. Place a test outbound call from the Voice Agent using the SIP trunk. 2. Confirm the receiving phone sees the expected caller ID. 3. Call the DID or extension from an outside phone. 4. Confirm the assigned Voice Agent answers. 5. Review the call logs for errors before launching a sequence or production workflow. *** ## Custom SIP headers If your carrier or PBX adds custom headers to the calls it sends to Dapta, for example `X-Customer-Data` or a `User-to-User` header with an encoded payload, the Voice Agent receives them as call variables: `{{sip_header_x-customer-data}}` holds the value as it arrived, and `{{sip_header_x-customer-data_decoded}}` holds the readable text when the header is `User-to-User` or its value declares `encoding=hex` or `encoding=base64`. The agent can also add headers to the calls it transfers, encoded or decoded as your PBX expects. The naming rules, the `|hex`, `|uui` and `|decode` filters and a worked example are on the Transfer Call page. {% content-ref url="/pages/qCIOdjGOCMlNQJwemM6b" %} [Transfer Call](/ai-voice-agents/agent-actions/transfer-call.md) {% endcontent-ref %} *** ## Troubleshooting | Issue | Likely cause | What to check | | -------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | Outbound call is rejected by the carrier | Wrong dial pattern, missing `+`, or unaccepted caller ID | Confirm **Dial Pattern**, full E.164 format, and registered caller ID with your carrier. | | Twilio rejects outbound calls | Termination domain, Credential List, IP ACL, caller ID, or number format is incorrect | Confirm the Twilio termination domain, SIP credentials or IP allowlist, accepted caller IDs, and E.164 format. | | Inbound calls do not reach the agent | DID/extension is not routed to Dapta or the wrong agent is assigned | Check carrier routing, that all of [Dapta's IPs](#dapta-ips-to-allow) are allowed, and the **Inbound Agent** setting. | | Twilio inbound calls do not reach Dapta | Origination SIP URI or phone number association is missing | Confirm the Twilio trunk has the Dapta-provided Origination SIP URI and that the Twilio phone number is associated with the trunk. | | Transfers or outbound calls fail right after you restrict the trunk, with a timeout and no answer from the trunk (SIP 408) | The firewall or IP allowlist blocks Dapta's SIP traffic | Allow all of [Dapta's IPs](#dapta-ips-to-allow), then place a test transfer. | | Transfers fail or never reach the human team | Transfer destination is not reachable by telephony or needs carrier-side configuration | Confirm the destination can be called directly and that any SIP transfer requirements are enabled by your carrier. | | **Dial Pattern** looks saved but changes after reload | The setting may not have persisted | Reopen the trunk, save again, and contact Support if the value still reverts. | | Calls connect but show the wrong caller ID | Carrier is overriding or rejecting the presented caller ID | Ask your carrier which caller IDs are registered and allowed for this trunk. | | Calls connect but audio is one-way or drops | Firewall, NAT, RTP, or codec behavior between the provider and Dapta | Ask the telephony admin to review SIP/RTP firewall rules, public IP handling, and supported codecs. | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.dapta.ai/ai-voice-agents/phone-numbers/connecting-your-sip-trunk/connect-your-own-sip-trunk-custom-byo.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.