SIP trunking looks simple on a network diagram. Production failures tend to hide in the details: signaling succeeds while audio fails, a codec mismatch rejects calls, or a campaign exceeds the carrier's call-rate limit. A sound design treats routing, media, security, capacity, and recovery as separate concerns. Here is the practical model technical teams need to select, deploy, and operate a SIP trunk.
SIP trunking in 60 seconds
Session Initiation Protocol (SIP) trunking is an IP connection between a business phone system or voice application and a telephony provider. The provider supplies access to the public switched telephone network (PSTN), so the system can receive and place calls to ordinary phone numbers.
A SIP trunk replaces the connectivity provided by analog lines or a Primary Rate Interface (PRI) circuit. The word trunk describes the logical connection. It is not a cable, and one trunk can carry many simultaneous calls.
Four concepts are easy to conflate:
- SIP is call signaling. It establishes, changes, and ends a session. The core protocol defines methods such as INVITE, ACK, and BYE and groups messages into transactions and dialogs. The SIP specification does not define the audio stream itself.
- RTP carries the media. Real-time Transport Protocol (RTP) normally carries voice packets on a separate set of ports. The RTP specification also defines sequence numbers and timestamps that help receivers handle real-time media.
- A phone number is an address. A direct inward dialing (DID) number can route calls through a trunk, but a number does not reserve a call channel.
- Two independent service limits are concurrent calls and calls per second (CPS). Concurrent calls determine how many sessions can stay active. CPS determines how quickly new sessions can start; network bandwidth and other provider limits are separate constraints.
For teams building voice AI, the SIP trunk is the carrier boundary, not the complete application. Our voice AI backend runs the real-time agent behind that boundary. You can keep your carrier and numbers, add manual SIP credentials, link numbers to agents, and set a CPS limit that matches the carrier. Our SIP configuration guide documents the current fields and supported signaling transports.
How SIP trunking works
A production path has several distinct components. Some vendors combine them, but the roles still exist.
| Component | Its job | What to confirm |
|---|---|---|
| Phone number | Identifies a PSTN destination and may be authorized and presented as outbound caller ID | Ownership, porting, geographic coverage, emergency calling support |
| Telephony provider | Connects IP calls to mobile and fixed-line networks | Regions, destinations, capacity, CPS, fraud controls, failover |
| Provider SBC | Enforces the carrier's network edge policies | Signaling and media IP ranges, ports, authentication, codecs |
| Customer SBC, PBX, or voice app | Routes calls and applies business logic | Public addressing, normalization, codec and DTMF support, redundancy |
| SIP signaling | Negotiates and controls the session | UDP, TCP, or TLS, plus SIP domains and headers |
| RTP or SRTP media | Carries the audio | Media IPs and ports, codec, packet time, symmetric RTP, encryption |
A typical outbound call
- The PBX or application sends an INVITE to the provider. Its Session Description Protocol (SDP) body proposes media addresses, ports, and codecs.
- The provider authenticates or authorizes the request, applies routing policy, and selects a PSTN route.
- Provisional responses such as 100 Trying, 180 Ringing, or 183 Session Progress describe call progress. Their exact use varies by route.
- A 200 OK accepts the INVITE. In the basic flow where the INVITE carried the offer, the 2xx carries the answer and may repeat an answer sent in a provisional response; the caller then sends ACK. If the 2xx carries the offer, the ACK carries the answer.
- RTP or Secure RTP (SRTP) carries the audio. It may flow between different IP addresses than the SIP messages.
- Either side sends BYE to end an established dialog, and the other side responds with a 2xx response, normally 200 OK.
An inbound call follows the same negotiation in the other direction. The provider receives a call for one of your numbers, maps it to your trunk, then sends an INVITE to the endpoint you configured.
SDP is the contract between signaling and media. It describes the proposed session, including connection information and media formats, as defined in the current SDP standard. If a SIP trace shows a completed handshake and the caller hears silence, inspect the negotiated SDP and RTP path before changing call routing.
SIP trunking compared with VoIP, PRI, and a hosted PBX
SIP trunking is one way to deliver Voice over Internet Protocol (VoIP). VoIP is the broader category for voice carried over IP networks.
| Term | What it describes | What you operate | Best fit |
|---|---|---|---|
| VoIP | Any voice communication carried over IP | Varies | The umbrella category |
| SIP trunk | PSTN connectivity for a SIP-capable PBX or application | Call control or application, often an SBC | Teams keeping their PBX, carrier choice, or application logic |
| PRI trunk | A physical digital circuit between a PBX and a carrier | PBX and on-premises circuit equipment | Existing sites with stable legacy infrastructure |
| Hosted PBX or UCaaS | A provider-managed business phone system | Users, devices, and policies | Teams that want calling and collaboration without operating call control |
| CPaaS voice API | Programmable calling exposed through an API | Application logic and integrations | Developers building custom call workflows |
A SIP-capable application can terminate a trunk directly. A traditional PBX is optional. Teams may place a session border controller (SBC) at the edge for access control, topology hiding, protocol interworking, media anchoring, and related policy enforcement.
The technical decisions that determine call quality
Authentication and inbound routing
A provider may authorize or locate a trunk by source IP, SIP Digest credentials, registration, or a provider-specific combination. The choice affects topology:
- IP authorization works well with stable public addresses and redundant SBCs. Only approved source ranges should reach the trunk.
- Digest authentication sends a challenge-response value after a SIP 401 or 407 challenge; it does not send the password itself. Store the password like any production secret and rotate it through a controlled process.
- Registration lets an endpoint tell the provider where it is reachable. It can suit dynamic endpoints, but registration state becomes another dependency to monitor.
Use E.164 for globally routable public numbers where the provider supports it, and explicitly document exceptions such as emergency, short-code, and private-extension dialing. Define how the provider presents the destination in the request URI and To header, and how it expects the outbound caller and destination. Routing that depends on an undocumented header is brittle and may break during a carrier or SBC change.
Signaling transport and media encryption
SIP over bare UDP or TCP has no transport encryption. SIP over TLS protects signaling only between each pair of TLS endpoints; it does not encrypt the separate RTP media stream.
Use SRTP when media confidentiality and integrity are required. SRTP adds protection to RTP and RTCP packets, while key negotiation still needs an agreed mechanism. The SRTP standard explains the cryptographic context and packet processing. Confirm the provider's exact TLS versions, certificate rules, SRTP profile, and keying method as one interoperability set.
Codec negotiation and transcoding
The SDP offer and answer list media formats and payload mappings. Usable audio requires an agreed compatible format and mapping, even though SIP signaling itself can still complete when the media path is unusable.
G.711 μ-law and A-law are common PSTN interop choices. Their codec bitrate is 64 kbit/s before IP packet overhead. Opus can provide wideband audio on compatible IP paths, but the PSTN segment may still reduce the call to narrowband audio. Every transcode adds processing and another place for level, tone, or quality problems.
For voice AI, test with real PSTN calls. A browser-only WebRTC test can sound better when it avoids carrier transcoding and the narrowband telephone path; a WebRTC-to-PSTN call may not. Measure speech recognition, synthesis, interruption handling, voicemail behavior, and transfers through the intended trunk.
DTMF transport
Interactive voice response menus and payment systems often depend on dual-tone multi-frequency (DTMF) digits. The trunk and application need the same transport method. Named telephone events carried in RTP are standardized by RFC 4733, which replaced the older RFC 2833. Some systems use in-band tones or proprietary or legacy DTMF conventions carried in SIP INFO instead.
Test digits during a live call, through every transcode and transfer path. A clean voice sample does not prove that DTMF works.
How to size a SIP trunk
Sizing one channel per employee can overprovision a trunk. Estimate simultaneous calls during the busiest interval, then treat call setup rate and network bandwidth separately.
Estimate concurrent calls
Average concurrency is a starting estimate, not a safe production limit:
average concurrent calls = calls per hour × average call duration in minutes ÷ 60
Assume 800 connected calls begin in the busiest hour and their average connected duration is four minutes. Estimated average connected concurrency is about 53. That is not a safe production limit because arrivals and durations cluster. Use interval-level traffic data, find a high percentile of observed concurrency, add room for retries and growth, and preserve capacity for inbound or transferred calls.
Measure attempted and connected concurrency separately. A campaign may generate many short ringing or failed attempts while only a smaller group reaches an answered state, yet those attempts still consume setup capacity and sometimes trunk channels.
Size calls per second
CPS controls how fast INVITE requests may enter the carrier. A trunk that supports 500 concurrent calls can still reject a burst of 50 new calls if its CPS limit is 10.
Queue outbound work and pace it below the contracted CPS. Apply the limit across all workers that share the trunk. In Dasha, SIP credentials include cpsLimit and an optional shared cpsKey, so multiple credentials can respect one provider-level allowance.
Reserve network bandwidth
Bandwidth depends on codec bitrate, packet interval, IP version, encryption, and Layer 2 overhead. With G.711 and 20 ms packets, allow roughly 80 to 100 kbit/s in each direction per active call as a planning range. Measure the actual encapsulation on your network before setting final limits.
Provision for the peak number of calls, then leave headroom for signaling, retransmissions, monitoring, and other traffic. Quality of service can prioritize voice on a congested private network, but it cannot repair congestion elsewhere on the public internet.
Security and reliability belong in the initial design
A trunk exposes a route into the telephone network. Misconfiguration can lead to call interception, toll fraud, number spoofing, denial of service, or unexpected charges.
Use these controls from the start:
- Where the provider publishes stable signaling and media ranges, allow only those ranges and maintain distinct firewall rules for signaling and media.
- Disable SIP Application Layer Gateway (SIP ALG) behavior unless the design explicitly depends on it. Middleboxes that rewrite SIP or SDP can create intermittent registration and one-way audio failures.
- Use TLS for signaling and SRTP for media when the complete path supports them. Document where encryption terminates.
- Restrict outbound destinations, caller identities, international dialing, and maximum call duration to the application's real needs.
- Rate-limit call attempts and authentication failures. Alert on changes in destination mix, average duration, answer rate, and spend.
- Keep SIP credentials out of source code and traces shared outside the operations team.
- Put SBCs, internet access, power, DNS, and carrier ingress in the failover plan. Redundant application instances behind one router still share one failure domain.
Reliability also needs an explicit routing policy. Define how calls move between provider points of presence or secondary carriers, whether in-progress calls can survive any component failure, and how inbound numbers reroute during an outage. Test the failure, including the return to the primary path. A configuration screenshot is not evidence of working failover.
A production rollout checklist
1. Inventory the existing call paths
Record numbers, number owners, call flows, extensions, queues, emergency locations, fax or modem use, recordings, DTMF dependencies, transfer targets, peak concurrency, CPS, codecs, and firewall rules. Separate features that must survive the cutover from unused legacy behavior.
2. Define the boundary
Choose whether the trunk terminates on an SBC, IP PBX, hosted application, or voice AI runtime. Assign ownership for number routing, fraud controls, certificates, codec policy, media anchoring, and call records.
3. Write an interoperability profile
Capture both sides of the contract in one document:
- SIP server names, ports, transports, domains, and authentication
- signaling and media IP ranges
- supported codecs, preference order, and packet interval
- DTMF method
- early media and provisional response behavior
- caller ID and number formats
- transfer method and diversion history
- concurrent call and CPS limits
- TLS, SRTP, certificate, and keying requirements
4. Configure the network edge
Create narrow firewall rules, NAT mappings, DNS, certificates, monitoring, and time synchronization. Confirm that SDP advertises reachable addresses. Keep tightly access-controlled, time-bounded SIP and packet captures available during the pilot; redact credentials and sensitive media before sharing.
5. Pilot with temporary numbers
Test inbound and outbound calls before porting a production number. Include mobile and fixed-line destinations, long calls, unanswered calls, busy destinations, voicemail, DTMF, hold, warm and cold transfer, and calls with silence or background noise.
6. Run failure tests
Interrupt each internet path, SBC, application instance, DNS target, and carrier route in a controlled window. Verify outbound pacing under burst load and inbound behavior at full concurrency.
7. Port numbers in stages
Group numbers by risk and business owner. Freeze unrelated PBX changes, keep a rollback or reroute plan for each batch, and compare provider and application call records after every move.
8. Operate the trunk with service-level indicators
Monitor call setup success, post-dial delay, answer rate, call duration, SIP response codes, RTP packet loss, jitter, round-trip time, one-way audio reports, DTMF success, transfers, active calls, CPS, and spend. Segment by provider route, destination, SBC, application version, and customer.
Common SIP trunking failures and what to inspect
| Symptom | Likely layer | Evidence to inspect first |
|---|---|---|
| No inbound calls | Number routing, firewall, or endpoint availability | Provider delivery log, incoming INVITE, request URI, destination header |
| 401 or 407 followed by success | Normal user-agent or proxy Digest challenge | Authorization or Proxy-Authorization on the retried request |
| Repeated 401 or 403 | Credentials, realm, IP allowlist, or policy | Challenge realm, source IP, username, provider rejection detail |
| 404 or 484 | Number formatting or route lookup | Request URI, E.164 normalization, assigned numbers |
| 408 or no response | DNS, network, firewall, or dead endpoint | Packet capture at both edges, DNS result, transport and port |
| 486 Busy Here | Destination or application rejected as busy | Call state and capacity at the receiving endpoint |
| 488 Not Acceptable Here | SDP, codec, SRTP, or media policy mismatch | SDP offer and answer, payload mappings, encryption profile |
| Call connects with one-way audio | NAT, firewall, or wrong SDP address | Advertised connection address and port, RTP packets at both edges |
| Choppy or delayed audio | Packet loss, jitter, congestion, or transcoding | RTP sequence gaps, jitter, route, codec changes, CPU saturation |
| DTMF fails | Mismatched DTMF method or payload type | SDP telephone-event, RTP events, SIP INFO, transcode path |
| Calls fail only during bursts | CPS or concurrent-call limit | Attempt rate, active calls, 503 responses (especially with Retry-After), provider-specific rate-limit events |
Start with a SIP ladder and the negotiated SDP, then correlate it with RTP metrics and application logs using a shared call identifier. Dasha exposes SIP traces by call, including the message order, source and destination, transport, response code, and raw SIP content. That closes the gap between a failed call in the agent runtime and the carrier exchange that caused it.
Connect SIP trunking to a production voice AI runtime
SIP trunking gives a voice product carrier choice, the ability to reuse or port eligible numbers subject to carrier and regulatory rules, and direct control of the telephony boundary. The work after connection still includes streaming media, turn-taking, speech recognition and synthesis, tools, transfers, testing, monitoring, and safe call execution.
We manage the voice AI runtime and platform infrastructure while technical teams can bring their carrier and numbers and retain responsibility for their telephony configuration and production acceptance. Start building with Dasha and connect the trunk and numbers you already use.