> 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/custom-telephony-for-enterprise-large-companies.md).

# Custom telephony for enterprise and large companies

Plan an enterprise custom telephony setup with Dapta, including dedicated SIP proxy routing, human transfers, concurrency, and onboarding requirements.

Enterprise telephony often needs more than a single self-serve trunk. Use this page when your setup needs a dedicated SIP proxy, fixed signaling, custom routing, warm or cold transfer to human teams, or more concurrent channels.

***

## When to use enterprise custom telephony

Use this path when your company needs:

* A dedicated Dapta-operated SIP endpoint with a fixed IP for stable signaling and routing policy.
* Header handling or custom routing rules between Dapta and your telephony platform.
* Warm or cold transfer from a Voice Agent to a human queue.
* Multiple trunks, regions, caller IDs, or PBX destinations.
* More concurrent channels than the base plan includes.
* A guided rollout with Dapta Success or Support.

***

## Step 1 - Contact Dapta Success or Support

Enterprise custom telephony is an implementer-assisted process. [Contact your Dapta Success or Support representative](https://calendly.com/dapta-support/support-30) before changing production routing.

Share the business goal first: inbound support, outbound sequences, appointment reminders, human transfers, contact center overflow, or another use case.

***

## Step 2 - Choose the telephony topology

Dapta will help you choose the right topology:

| Topology                                | Best for                                                                                                                 |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Direct custom SIP trunk**             | A simpler carrier or PBX setup where Dapta can register directly to your trunk.                                          |
| **Dedicated SIP proxy**                 | Enterprise setups that need fixed signaling, custom header handling, routing policy, or multiple telephony destinations. |
| **Voice Agent to human queue transfer** | Calls start with a Dapta Voice Agent and then move to a human team when needed.                                          |

A dedicated SIP endpoint is operated by Dapta and can sit between Dapta's voice platform and your carrier, PBX, or contact center. Dapta provisions it for enterprise implementations that need a fixed signaling IP or more control over headers and routing behavior. Dapta Support configures this endpoint with you during onboarding.

***

## Step 3 - Prepare the onboarding details

Your telephony admin should provide:

1. **SIP host / domain** and **port** for each carrier or PBX trunk.
2. **SIP auth username** and **SIP auth password** for each trunk.
3. **DIDs**, extensions, and caller IDs that Dapta may use.
4. The list of caller IDs your carrier will accept for outbound calls and transfers.
5. The inbound routing goal for each DID or extension.
6. The outbound use cases, such as sequences, test calls, or Flow Studio calls.
7. Human queue phone numbers or SIP destinations for warm and cold transfer.
8. Required SIP headers or metadata that must travel with the call.
9. Expected concurrent call volume and launch timeline.

If your carrier or PBX requires IP allowlisting, allow every IP and range in [Dapta IPs to allow](/ai-voice-agents/phone-numbers/connecting-your-sip-trunk/connect-your-own-sip-trunk-custom-byo.md#dapta-ips-to-allow).

***

## Step 4 - Plan warm and cold transfer to a human queue

Transfers from a Dapta Voice Agent to a human team happen over telephony and SIP. They are not an API handoff.

Supported high-level flow:

1. The caller reaches, or is called by, a Dapta Voice Agent.
2. The Voice Agent decides that a human should take over.
3. For a **cold transfer**, Dapta sends the call to the human queue immediately.
4. For a **warm transfer**, Dapta passes context before or during the handoff so the human team understands the conversation.
5. The human queue answers the transferred call through your telephony system.

The transfer destination must be reachable by telephony. If an IVR menu answers first, a cold transfer can't get past it and may not reach the right person or queue. A warm transfer with **IVR Navigation** turned on, or an agentic warm transfer whose screening agent has a **Press Digit (IVR Navigation)** action, presses the menu options you describe to reach the queue.

For agent action setup, see:

{% content-ref url="/pages/qCIOdjGOCMlNQJwemM6b" %}
[Transfer Call](/ai-voice-agents/agent-actions/transfer-call.md)
{% endcontent-ref %}

***

## Step 5 - Plan concurrency and channels

Your plan sets how many calls can be live at the same time, split into separate inbound and outbound limits: Enterprise includes **30 concurrent calls, 15 inbound and 15 outbound**. See [Concurrent calls](/ai-voice-agents/phone-numbers/concurrent-calls.md) for every plan. If your use case needs more simultaneous calls on either side, coordinate with Dapta before launch so capacity can be increased and tested with your carrier.

For outbound sequences, ramp gradually. Start with a lower volume, confirm answer rates and carrier behavior, then increase toward the target concurrency.

***

## Step 6 - Test before production

Before launch, test every path with your Dapta and telephony teams:

1. Outbound call through the trunk.
2. Inbound call from an external phone to the assigned Voice Agent.
3. Warm transfer to the human queue.
4. Cold transfer to the human queue.
5. Caller ID behavior for outbound and transferred calls.
6. Expected concurrency under a controlled load test.

***

## What Dapta provides and what you provide

| Area           | Your team provides                                                                        | Dapta provides                                                                                         |
| -------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| SIP trunk      | Carrier/PBX host, port, credentials, DIDs, and allowed caller IDs                         | Trunk configuration in Dapta and guided validation                                                     |
| Network access | Allow the signaling IPs provided by Dapta Support                                         | Dapta signaling endpoint and implementation support                                                    |
| Routing        | Desired inbound, outbound, and transfer destinations                                      | SIP proxy routing policy when needed                                                                   |
| Human transfer | Reachable human queue destination, plus the menu options to press if an IVR answers first | Cold, warm or agentic warm transfer setup from the Voice Agent                                         |
| Concurrency    | Required call volume, inbound and outbound, and carrier channel limits                    | Your plan's concurrent calls (15 inbound and 15 outbound on Enterprise) and a scaling plan when needed |

{% hint style="warning" %}
Do not publish or paste SIP passwords, carrier hostnames, production IPs, or production extensions into public tickets or shared documents. Use the secure process provided by Dapta Support or your implementation contact.
{% endhint %}


---

# 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/custom-telephony-for-enterprise-large-companies.md?ask=<question>&goal=<user_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.