How SIP Trunks Work

A SIP trunk is the link between a company's phone system (the PBX) and the public telephone network, delivered over an IP connection instead of copper lines or an ISDN circuit. The provider accepts calls from the PBX and sends them on to the destinations your plan allows, and routes calls to your public numbers back to the PBX. Technically a trunk is ordinary SIP as defined in RFC 3261: the same INVITE, REGISTER and BYE messages that a desk phone uses. What makes it a trunk is its role. It carries many calls at once, it is authenticated once for the whole PBX rather than per user, and it owns the public numbers. Softphones and desk phones do not talk to the trunk directly; they register to the PBX as extensions, and the PBX decides when a call needs the trunk.

This article explains the pieces: trunks versus extensions, the two ways a trunk is authenticated, DIDs, codecs, channels, and where a softphone such as SIPdia sits in the picture.

Trunks versus extensions

Think of the PBX as having two sides.

On the inside are extensions: the phones, softphones and voicemail boxes of your users. Each extension has a short number such as 1002, a password, and a registration to the PBX. Calls between extensions stay on the PBX and do not use the trunk.

On the outside is the trunk: the connection to the provider. When an extension dials a number that is not another extension, the PBX dial plan picks a trunk and sends an INVITE to the provider. When someone in the world dials one of your public numbers, the provider sends an INVITE over the trunk, and the PBX rings the right extension, ring group or queue.

Before IP telephony this outside connection was a physical line. A SIP trunk replaces it with a SIP peer: a host name, a port, credentials and a list of allowed codecs. Because nothing physical is involved, the number of simultaneous calls is a contract term rather than a count of wires.

Registration versus IP authentication

The provider has to know that calls arriving from your PBX are really yours, and where to send inbound calls. There are two common methods.

Registration. The PBX acts like a very large phone. It sends REGISTER to the provider with a username and password, exactly as an extension does toward the PBX, and refreshes the registration before it expires. The provider stores the PBX's current address and sends inbound calls there. Registration suits PBXs behind NAT or with a changing public address, because the provider always learns the latest location. RFC 6140 describes how a single registration can cover a whole block of numbers rather than one address of record per number.

IP authentication. The provider stores the fixed public IP address of your PBX and accepts calls that come from it without a password. Inbound calls are sent to that address. This needs a static IP and a firewall rule that allows the provider's addresses in, but it avoids registration timers and shared passwords. Many business trunks use this method.

Both methods are then used for every call. Outbound, the PBX sends INVITE to the provider's host, which is found through DNS SRV records as described in RFC 3263 when no port is given. Inbound, the provider sends INVITE to the registered or configured address.

DIDs: your public numbers

DID stands for direct inward dialing. A DID is a public telephone number that the provider routes to your trunk. The term comes from the days when a block of numbers was mapped onto a trunk group so outside callers could reach a desk directly without going through an operator.

With a SIP trunk the provider holds the numbers and, for each inbound call, puts the dialled number in the INVITE. The PBX reads it and applies an inbound route: number 1 rings reception, number 2 rings the sales queue, number 3 goes straight to a named extension. One trunk can carry hundreds of DIDs from different cities or countries, and the mapping lives in the PBX, not in the provider's network.

Outbound caller ID works the other way. The PBX tells the provider which of your DIDs to present as the calling number. Many providers check that the number belongs to you before passing it on.

Codecs: how voice travels

SIP sets up the call; the voice itself travels in RTP packets, defined in RFC 3550. A codec turns audio into those packets and back. During call setup the PBX and provider exchange their codec lists and agree on one per call.

• G.711, in its ulaw (PCMU) and alaw (PCMA) variants, is the codec of the classic telephone network and is accepted by nearly every provider. It uses 64 kbit/s of payload per direction, about 80 to 90 kbit/s with packet overhead. RFC 3551 lists its RTP payload types.
• G.729 compresses to 8 kbit/s and is used where bandwidth is scarce, at the cost of some quality and of licensing on some equipment.
• G.722 offers wideband audio at 64 kbit/s and is common between extensions inside a PBX, less so on trunks.
• Opus (RFC 6716) adapts from a few kbit/s to full-band audio and is increasingly offered by providers.

The codec on the trunk and the codec on the extension side can differ. The PBX transcodes when needed, which costs CPU, so administrators often allow the same codec on both sides. The VoIP bandwidth calculator shows how much bandwidth each codec needs per channel.

Channels: how many calls at once

A channel is one simultaneous call on the trunk, in either direction. A trunk with ten channels can carry ten conversations at the same time, regardless of how many extensions or DIDs you have. When all channels are busy, the PBX cannot place another outside call, and inbound callers hear busy or are rejected with a SIP error, depending on the provider.

Providers sell channels in fixed bundles, as a monthly count, or bill per minute with a soft limit. Sizing is about the busiest moment of the day, not headcount: a 50-person office with light phone use may need five channels, while a small support team on the phone all day may need one per agent. Bandwidth follows the channel count. Ten G.711 calls need about 900 kbit/s in each direction, which an office connection handles easily, but it should be prioritised over other traffic to keep call quality steady.

Where a softphone sits

A softphone is an extension. It registers to the PBX with a username and password, places calls through the PBX, and receives calls that the PBX routes to it. The trunk is invisible to it. When you dial an outside number in a softphone, the PBX accepts the INVITE from the softphone, applies its dial plan, and sends a new INVITE over the trunk to the provider. Audio flows softphone to PBX to provider, unless the PBX is configured to let the endpoints exchange RTP directly.

This has three practical consequences:

1. Credentials. The softphone never needs the trunk's password or IP authentication. It needs the extension's server, username and password, which the PBX administrator creates.
2. Features. Hold, transfer, forwarding, voicemail and feature codes are provided by the PBX. The softphone sends the requests; the PBX executes them and talks to the trunk when a call must leave the building.
3. Reachability. The PBX must be reachable from wherever the softphone is: on the office network, over a VPN, or through NAT handling on the PBX. The trunk's reachability is a separate matter between PBX and provider.

The one exception is when a provider sells individual SIP accounts rather than trunks. Then the softphone registers directly to the provider, and the provider plays the PBX's role with a smaller feature set. SIPdia supports both arrangements through the same Account fields; SIP Registration: PBX Extension vs Provider Account compares them.

A call from start to finish

Putting it together, here is what happens when a user on a softphone calls an outside number:

1. The softphone sends INVITE to the PBX with the dialled number.
2. The PBX checks the dial plan, sees an outside number, and picks a trunk.
3. The PBX sends INVITE to the provider's host over the trunk, with the caller ID set to one of your DIDs.
4. The provider authenticates the call by registration or by source IP, and routes it to the destination network.
5. The destination answers; 200 OK travels back through the provider and the PBX to the softphone.
6. RTP audio flows between the softphone and the PBX, and between the PBX and the provider, using the codecs negotiated on each leg.
7. Either side hangs up; BYE travels the same path and the channel is freed.

Next steps

• New to SIP terms? Start with What is a SIP account?.
• Comparing options for your own softphone? Read SIP Registration: PBX Extension vs Provider Account.
• Received individual SIP credentials from a provider? Follow How to Connect a Softphone to an ISP or Provider SIP Account to register SIPdia to them.