How SIP trunking works

A SIP trunk is a logical IP connection that carries phone calls between a business communications system and a telephony service. SIP signaling creates, changes, and ends each call session; the session description negotiates where audio should flow and which formats it may use; and a separate media stream normally carries the actual sound. Unlike an analog line, a trunk is not one physical wire per call. It is a configured trust and routing relationship that can support multiple simultaneous sessions over the same network connection.

What the “trunk” actually is

In traditional telephony, a trunk grouped circuits between switches. SIP trunking preserves that role—connecting two telephone domains—but replaces dedicated voice circuits at the handoff with Internet Protocol networking and SIP. One side is commonly a PBX, session border controller, contact center, or voice application. The other side is a carrier or another SIP-capable network.

The trunk consists of configuration and capacity rather than a permanent call tunnel. Its definition may include:

The source and destination IP addresses or domain names allowed to exchange signaling.
Authentication credentials, IP allowlists, or both.
Transport choices such as UDP, TCP, or TLS for signaling.
Number-routing rules for inbound and outbound calls.
Permitted codecs, DTMF methods, caller identity fields, and session timers.
A concurrency limit defining how many call sessions may be active at once.
Primary and failover destinations.

A SIP trunk is therefore not the same thing as a phone number. A number is an address in the public numbering plan. The trunk is one path by which calls to or from that address reach a phone system. Several numbers can route over one trunk, and a single system can use multiple trunks.

The identities involved in a SIP call

SIP messages contain several identities that serve different purposes. A SIP URI looks roughly like an email address: it names a user or service at a domain. Public calls also carry telephone numbers, usually normalized into an international form. A carrier may route the call by the number in the request target while presenting a different identity to the recipient as caller ID.

That distinction matters because one message can include the dialed destination, the asserted identity of an authenticated caller, a display identity, a redirecting party, and a network address for responses. Treating every identity-bearing header as interchangeable creates routing errors and caller-ID problems. Trunk configuration should explicitly state which field is authoritative for each function and which party is trusted to assert it.

For inbound service, a carrier associates one or more DID numbers with the trunk. When someone dials a DID, the carrier resolves its customer routing record and sends a SIP request toward the configured destination. For outbound service, the business system sends a request to the carrier, which validates the trunk, evaluates the destination and presented identity, then routes the call onward.

Call setup: INVITE, SDP, and responses

Consider an outbound call from a PBX through a trunk. The exact route may cross proxies and border controllers, but the core transaction is recognizable:

INVITE. The originating system sends a SIP INVITE naming the destination. The message contains call identifiers, routing headers, the caller's identity, and usually a Session Description Protocol offer.
Provisional responses. A downstream system can return 100 Trying to show that processing has started, then 180 Ringing when the destination is being alerted. A 183 Session Progress response can establish early media, such as a network announcement, before answer.
Final response. A successful answer returns 200 OK, normally with an SDP answer. A rejection or failure uses a different final response indicating conditions such as busy, not found, forbidden, or temporarily unavailable.
ACK. The caller sends ACK for the successful final response. At that point the SIP dialog is established.
BYE. Either side can later send BYE to end an established session. The other acknowledges it, and both sides release call state.

If the caller abandons the attempt before answer, it sends CANCEL rather than BYE. That distinction is useful in troubleshooting and analytics: a cancelled call was never fully established, while a BYE ends an active dialog.

SIP transaction state also handles retransmission. UDP does not guarantee delivery, so endpoints retransmit certain messages on timers until a response arrives or the transaction expires. TCP and TLS provide reliable transport, but SIP still has its own transaction and dialog rules. Duplicate messages are not necessarily duplicate calls; systems must recognize them by branch, tag, sequence, and call identifiers.

SDP decides how media can flow

SIP describes the conversation; Session Description Protocol describes the proposed media. An SDP offer identifies media types, IP addresses, ports, codec payloads, and related capabilities. The answer selects a compatible subset. This offer-answer exchange may occur in the initial INVITE and response or in a later reliable exchange, depending on the call flow.

Codec lists are ordered preferences, not a guarantee that the first name will survive end to end. One side may offer G.711, G.722, and Opus while an interconnecting network supports only a subset. The selected audio codec determines how samples are represented on that media leg. If a gateway connects a different codec on the far leg, it transcodes between them.

SDP addresses deserve close attention. A SIP message may correctly traverse a proxy while its SDP advertises an unreachable private address. The call then signals normally but has no audio. A session border controller often rewrites SDP and anchors media so both endpoints send packets to reachable addresses. This helps with network boundaries and policy enforcement, although it adds another media hop.

The audio usually does not travel inside SIP

Once media parameters are agreed, audio normally flows as RTP, not as SIP payloads. Each RTP packet carries a sequence number, timestamp, payload type, and a short block of encoded audio. The receiver uses sequence numbers to detect loss or reordering and timestamps to play samples at the right cadence.

The media topology can differ from the signaling topology. SIP might pass through several proxies while RTP flows directly between endpoints. Alternatively, a border controller, media server, recorder, or transcoder may anchor the audio and create two separate RTP legs. A packet capture on the SIP proxy will not reveal audio if that machine is not in the media path.

This separation explains several common symptoms:

The call never rings: investigate SIP routing, authentication, or rejection responses.
The call connects with silence: inspect SDP addresses, media ports, firewall policy, and codec selection.
Only one party can hear: compare the two RTP directions; network address translation or asymmetric filtering often affects only one.
Audio begins, then the call ends: check session timers, re-INVITE handling, and whether a border device expects media activity.

Inbound and outbound routing

Inbound routing starts with the public number. The carrier maps that number to a trunk and sends an INVITE to a configured domain or IP target. The receiving edge validates the source, normalizes the destination, and chooses an internal application, queue, or extension. If there are multiple targets, the carrier or customer edge may try them in priority order when a destination is unavailable.

Outbound routing reverses the trust direction. The PBX or application selects a trunk based on the dialed number, location, policy, or cost. The carrier authenticates the sender, verifies that the destination is permitted, and hands the call to the next network. A route can fail before reaching the called device, so the final SIP response may originate from an intermediate system rather than the human recipient's endpoint.

Number normalization is essential in both directions. Users may dial local digits, a national prefix, or a fully qualified international number. Internal routing should convert these variants into one canonical representation before applying policy. Display formatting belongs at the user interface, not in the routing key.

DTMF, hold, transfers, and mid-call changes

Voice is not the only information transported during a call. Touch-tone digits may be sent as audible tones, separate RTP telephone events defined by RFC 4733, or SIP INFO messages. The two trunk endpoints must agree on a method. A mismatch produces a familiar failure: speech works, but an automated menu never detects keypresses.

SIP can also modify an established dialog. A re-INVITE or UPDATE can renegotiate media, for example to place a party on hold by changing the advertised media direction. Transfers can be implemented by keeping the original system in the media path and bridging a new call leg, or by using SIP REFER to ask another endpoint to contact a new destination. Bridging provides more application control; a successful REFER can release the transferring system from the media path. The mechanics and trade-offs are covered in how call transfers work.

Any mid-call negotiation must preserve dialog identifiers and increase the SIP sequence number correctly. Simultaneous re-INVITEs can collide, so endpoints need retry behavior. A trunk that passes basic calls can still fail on hold or transfer if these less common flows were never tested.

Security boundaries

SIP trunk security begins with a clear trust model. IP authentication is operationally simple but assumes source addresses cannot be spoofed through the accepted network path and that address changes are coordinated. Digest credentials authenticate requests but must be protected and rotated. TLS encrypts and authenticates the signaling transport hop by hop; it does not automatically encrypt RTP media. SRTP protects media, provided the endpoints also negotiate keys securely.

Border controls should limit accepted source networks, methods, destinations, and caller identities. Rate limits and concurrency limits constrain abuse. Outbound dial permissions should prevent unexpected international or premium destinations. Logs should preserve enough detail to investigate fraud—request source, authenticated identity, destination, response, and call duration—without exposing credentials.

Do not assume that placing SIP on a nonstandard port is a security control. Internet scanners can find services on arbitrary ports. Authentication, access control, patching, anomaly detection, and restricted routing are the substantive defenses.

Capacity, resilience, and failover

Because a trunk is logical, capacity is usually expressed as concurrent calls rather than wires. Signaling rate matters during bursts as well: a campaign or outage can generate many short attempts even when few become active. Media bandwidth depends on the codec plus packet and encryption overhead, not just the codec's nominal bit rate.

Resilience requires both signaling and media planning. A secondary SIP destination is not useful if DNS, firewall rules, or credentials only work for the primary. Likewise, a backup signaling edge may accept calls while advertising a media network that the carrier cannot reach. Health checks should test a representative call path, including audio in both directions, rather than only confirm that a port is open.

For inbound failover, decide which failures trigger the next target and how long each attempt may consume. For outbound failover, avoid retrying responses that represent a definitive policy rejection. Every new attempt should carry traceable identifiers so operators can distinguish one user call from its multiple routing legs.

A practical troubleshooting sequence

Start with the signaling exchange and follow the call in order:

Confirm that the INVITE reached the expected edge and matched the intended trunk.
Check the final SIP response and which system generated it.
Compare the SDP offer and answer: addresses, ports, media direction, codecs, and DTMF method.
Verify RTP packets in each direction and inspect sequence gaps and payload types.
Follow any re-INVITE, UPDATE, REFER, or BYE that coincides with the failure.
Correlate the same call across carrier, border controller, and application logs using SIP identifiers and timestamps.

This order prevents media debugging on a call that never answered and application debugging on an INVITE that never reached it.

FAQ

Is a SIP trunk the same as VoIP?

No. VoIP is the broader practice of carrying voice over IP networks. A SIP trunk is one way to connect phone systems or services, using SIP for call control and usually RTP for media.

Does every simultaneous call need a separate SIP trunk?

No. One trunk can carry multiple concurrent dialogs. The service configuration, network, and receiving systems determine the supported concurrency.

Can a SIP trunk use an existing business number?

Yes, if the number is routed or ported to a service that can deliver it over the trunk. The number and the trunk remain separate resources, and porting changes the public routing assignment rather than the number itself.

What does bring your own carrier mean?

Bring your own carrier means the application uses a telephony provider selected and managed by the customer. The connection is commonly a SIP trunk, with routing, authentication, numbers, and support responsibilities divided between the application and carrier.