π’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 before changing production routing.
Share the business goal first: inbound support, outbound campaigns, 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:
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:
SIP host / domain and port for each carrier or PBX trunk.
SIP auth username and SIP auth password for each trunk.
DIDs, extensions, and caller IDs that Dapta may use.
The list of caller IDs your carrier will accept for outbound calls and transfers.
The inbound routing goal for each DID or extension.
The outbound use cases, such as campaigns, test calls, or Flow Studio calls.
Human queue phone numbers or SIP destinations for warm and cold transfer.
Required SIP headers or metadata that must travel with the call.
Expected concurrent call volume and launch timeline.
If your carrier or PBX requires IP allowlisting, Dapta Support will provide the signaling IPs to allow during onboarding.
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:
The caller reaches, or is called by, a Dapta Voice Agent.
The Voice Agent decides that a human should take over.
For a cold transfer, Dapta sends the call to the human queue immediately.
For a warm transfer, Dapta passes context before or during the handoff so the human team understands the conversation.
The human queue answers the transferred call through your telephony system.
The transfer destination must be reachable by telephony and should not have an IVR between the Dapta transfer and the human queue. If an IVR answers first, the transfer may not reach the right person or queue.
For agent action setup, see:
πTransfer CallStep 5 - Plan concurrency and channels
The base plan includes 20 concurrent channels. If your use case needs more simultaneous calls, coordinate with Dapta before launch so capacity can be increased and tested with your carrier.
For outbound campaigns, 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:
Outbound call through the trunk.
Inbound call from an external phone to the assigned Voice Agent.
Warm transfer to the human queue.
Cold transfer to the human queue.
Caller ID behavior for outbound and transferred calls.
Expected concurrency under a controlled load test.
What Dapta provides and what you provide
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 without an IVR in between
Warm or cold transfer setup from the Voice Agent
Concurrency
Required call volume and carrier channel limits
Base 20 concurrent channels and a scaling plan when needed
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.
Last updated