> 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/connecting-your-sip-trunk/connect-your-own-sip-trunk-custom-byo.md).

# Connect your own SIP trunk (custom / BYO)

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="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 %}

***

## 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/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, `<your SIP host>` 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.

If your carrier or PBX requires IP allowlisting, [contact Dapta Support](https://calendly.com/dapta-support/support-30) to get the signaling IPs your carrier should allow.

***

## 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**            | Optional Twilio allowlist for Dapta's signaling IP instead of, or 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 `<your-trunk>.pstn.twilio.com`.
4. Create a **Credential List** for Dapta or allow Dapta's signaling IP 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 `<your-trunk>.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 or IP allowlisting.                                |
| 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.                         |

For providers that require IP allowlisting, [contact Dapta Support](https://calendly.com/dapta-support/support-30) to get the signaling IPs your provider should allow.

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**.

<figure><img src="/files/GWwv3FdplL3SgxlpLD5a" alt="Dapta Sip Trunks page showing the search field, New Sip Trunk Extension button, and trunk table columns"><figcaption><p>Use the Sip Trunks page to add and manage SIP trunk extensions for Voice Agents.</p></figcaption></figure>

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 Dapta's signaling IP if IP allowlisting is required.

{% 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. If your carrier requires IP allowlisting, make sure the signaling IPs provided by Dapta Support 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 campaign or production workflow.

***

## 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, Dapta's allowed signaling IP, 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 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.dapta.ai/ai-voice-agents/connecting-your-sip-trunk/connect-your-own-sip-trunk-custom-byo.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
