How does SIP trunking work?

SIP trunking works by turning a phone call into data that rides your existing internet connection, then splitting that call into two streams that do different jobs. One stream is signaling, run by the Session Initiation Protocol, which is the standard the industry uses to start a call, change it mid-stream, and end it.[2] The other stream is the media, the actual audio, which travels as Real-time Transport Protocol packets on its own path.[6] Your phone system, usually an IP-PBX, hands each outbound call to an internet telephony service provider over the trunk, and that provider passes the call into the public switched telephone network so it can reach any mobile or landline number.[1] Nothing about that link is a physical wire in the way a T1 or PRI circuit was, because the trunk is a software session whose capacity is counted in how many calls can run at once rather than in copper pairs.[1][14]

The two streams stay separate because they have different needs. Signaling has to be reliable and understood by every device in the path, so SIP is a text-based, request-and-response protocol modeled on HTTP, which makes each message readable and easy for servers to route.[2] Audio has to arrive quickly and in order, so RTP stamps every packet with a sequence number and a timestamp, letting the far end rebuild the sound even when packets arrive out of order.[6] A single call therefore involves a short conversation of SIP messages to agree on terms, followed by a continuous flow of RTP once both ends are connected. The sections below follow one call from the moment your system dials to the moment someone hangs up, since the order of events is where the mechanics are easiest to see.

In stage one your phone system locates the provider's servers and proves it is allowed to use the trunk. Finding them is a DNS job: SIP resolves the provider's domain into an IP address, port, and transport protocol using a defined sequence of NAPTR, then SRV, then A or AAAA record lookups, which lets a provider publish several servers and steer traffic without you hard-coding an address.[7] Once the next hop is known, the system authenticates, and providers generally accept one of two methods. With IP authentication the provider configures its system to accept SIP traffic only from your office's static public IP address, so a call from anywhere else is refused.[10] With digest authentication the provider challenges the request, and your system answers with a hash that proves it knows the password without ever sending that password across the network in cleartext.[10] Registration-based trunks re-send that proof on a timer so the provider always knows where to deliver inbound calls, which matters for a system whose address can change. This stage is a frequent cause of calls that fail the instant you dial, so confirming that the provider's expected authentication method matches how your system is addressed is worth doing before cutover.

Setup begins when your system sends a SIP INVITE toward the provider, and that INVITE carries the terms of the call inside a Session Description Protocol body. SDP lists the media your side wants to use, including the audio codecs it supports and the IP address and port where it expects to receive the audio.[5] That is the offer in the offer/answer model, and the far end replies with an answer that keeps only the codecs it also supports and gives the address and port where it wants to receive media, so both ends converge on a shared set before any audio flows.[3] While that negotiation happens, the provider's server sends back progress responses, such as 100 Trying to show the request arrived and 180 Ringing to show the far phone is alerting.[4] When the call is answered, a 200 OK carries the final media terms, and your system replies with an ACK to confirm the handshake is complete and the call is up.[4][2] In most business deployments a session border controller sits in this path as a back-to-back user agent, which means it ends the provider's SIP session and starts a fresh one toward your PBX, rewriting addresses so private phones can reach a public provider and hiding your internal network layout in the process.[8]

During stage three the spoken audio leaves the SIP path entirely and travels as its own stream of RTP packets between the two addresses the offer and answer agreed on. RTP is built for real-time data such as audio, and it tags every packet with a sequence number and a timestamp so the receiver can play the sound back in the right order even when packets arrive late or out of sequence.[6] A companion protocol, RTCP, rides alongside and reports on quality, giving each side feedback on packet loss and timing that it can act on.[6] Keypad presses during the call, such as the digits you enter for a phone menu, are usually sent as named RTP telephone events rather than as tones inside the audio, which keeps them accurate after the audio has been compressed.[9] How much bandwidth the media needs depends on the codec: the common G.711 codec uses roughly 85 to 87 kilobits per second in each direction once packet headers are counted, while the more compressed G.729 drops that to about 31 kilobits per second per direction.[11] Because voice is sensitive to delay and jitter, many deployments route the media through the session border controller so the provider sees one known address, and they give voice packets priority on the local network so a busy link does not turn into choppy audio.[8]

The final stage is the provider connecting your call to the public switched telephone network and, eventually, tearing it down. Your INVITE only reaches the provider's edge, and from there the provider routes the call across its own connections to other carriers so it can terminate on any landline or mobile number, while inbound calls travel the reverse route to the direct inward dial number that maps to a person or department.[1][14] Because the service lets users both place and receive calls on the public network, it meets the federal definition of an interconnected VoIP service, which requires real-time two-way voice, a broadband connection, and IP-compatible equipment.[12] When either party hangs up, that side sends a SIP BYE, the other confirms with a 200 OK, and both ends stop the RTP stream and release the path for the next call.[2][4] The channel released is not a physical thing to reclaim, since it is simply one of the concurrent call paths the provider counts, so freeing it returns capacity in software rather than hardware. Sitting under the interconnected VoIP rules also means the provider carries 911 duties, including transmitting every 911 call with a call-back number and location and telling subscribers plainly that 911 can fail during a broadband or power outage.[13]

A SIP trunk depends on your internet connection and exposes your phone system to the public network, so a few limits deserve planning that a legacy circuit did not need.

It only works while the internet and power hold up

A SIP trunk rides your data connection, so if that link or the local power fails, the trunk stops carrying calls, unlike an old analog line that drew its power from the phone company. Sites that cannot tolerate dead phones usually pair the trunk with a second internet path and battery backup, and they configure the provider to reroute calls to mobiles or another location when the primary link goes quiet.

An internet-facing phone system can be attacked

Because the trunk reaches the public internet, an exposed or misconfigured system can be found and abused to place expensive international calls, which is why authentication, encryption of signaling and media, and provider-side limits on call destinations and spending all matter.[10] A session border controller helps here by refusing malformed or unauthorized SIP traffic at the edge before it reaches your PBX.[8]

Emergency calling needs accurate location records

Falling under the interconnected VoIP rules means the provider must route 911 with a call-back number and a usable location, and because a single trunk can serve numbers registered at different addresses, keeping each number's location current is an ongoing task rather than a one-time setup.[13]

Quality depends on the connection, not just the codec

Voice shares the link with everything else on your network, so a connection that handles email without complaint can still produce broken audio when it saturates during busy periods. Giving voice traffic priority and leaving enough headroom for the number of simultaneous calls is what keeps the audio clean once the link fills up.[11]

SIP trunking is one specific way to connect a phone system to the outside world, and understanding how it works clears up several things it gets confused with.

It is not the SIP protocol by itself

SIP is the signaling standard that sets up sessions for many uses, including video and messaging, while a SIP trunk is a commercial service built on that protocol to carry voice between your phone system and a carrier.[2] In practice you buy the trunk as a service, and it uses SIP internally to handle each call.

It is not a hosted or cloud phone system

With a SIP trunk you keep running your own phone system, on-site or as a virtual machine, and the trunk only connects it to the outside world.[1] A hosted PBX or UCaaS product moves the whole phone system into a provider's data center, so the two solve different parts of the problem and are sometimes deployed together.

It is not VoIP as a whole

VoIP is the broad category of carrying calls over IP networks, and SIP trunking is one form of it aimed at linking a phone system to the public network.[1] A softphone app or a fully hosted service is also VoIP without being a SIP trunk.

It is not the audio path

The signaling you configure and watch is SIP, but the audio never travels inside those SIP messages, since it moves as a separate RTP stream that can take a different route through the network. That split is why a call can show as connected in your PBX while an audio fault traces back to the media path instead of the signaling.[6]