🔌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.
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.
Common BYO SIP trunk scenarios
Your company owns the Twilio account or Twilio phone numbers
Your company uses another SIP carrier, PBX, SBC, or contact center
You need dedicated routing, SIP proxy behavior, human queue transfer, or higher concurrency
In this guide, "Twilio" means your own Twilio account. It is not the same as a Dapta-managed number purchased inside Dapta.
Step 1 - Gather your trunk credentials
Ask your carrier or PBX admin for:
SIP host / domain and port - for example,
<your SIP host>and port5060.SIP auth username and SIP auth password.
The DID(s) or extension Dapta should use.
Which caller IDs the carrier will present and accept.
Whether the trunk should support outbound, inbound, or both.
The number of concurrent channels your carrier has provisioned.
If your carrier or PBX requires IP allowlisting, contact Dapta Support 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
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:
Create or open an Elastic SIP Trunk in Twilio.
Configure Termination for that trunk.
Share the trunk's Termination SIP URI with Dapta, such as
<your-trunk>.pstn.twilio.com.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.
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.
Confirm that outbound destination numbers will be sent in full E.164 format with the leading
+, such as+15555550123.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:
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.
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.
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:
Configure Origination on the Twilio trunk.
Set the Origination SIP URI to the Dapta-provided SIP URI.
Associate the Twilio phone number with the trunk.
Confirm Twilio can reach the Dapta SIP URI from the selected Twilio edge or region.
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.
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.
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:
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 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.
Fill in the trunk fields using generic carrier values:
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.
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.
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.
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:
Place a test outbound call from the Voice Agent using the SIP trunk.
Confirm the receiving phone sees the expected caller ID.
Call the DID or extension from an outside phone.
Confirm the assigned Voice Agent answers.
Review the call logs for errors before launching a campaign or production workflow.
Troubleshooting
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.
Last updated