A trunk is the boundary where the carrier decides which calls your equipment may send and receive. If you have a PBX, the business phone system that routes your calls, a session border controller, a contact-center platform or any other SIP client, the trunk is how its calls get to the outside world and how outside calls get to it. A session border controller is the device that guards the edge of a voice network.
The first question is usually whether you need one at all, and the answer is yes. What varies is what you put behind it.
Do I actually need a trunk?
Yes. What differs between setups is the client on your side, not whether there is a trunk.
Every call to or from the telephone network crosses one, because the trunk is where the platform decides whether to accept the call at all. Two shapes are common:
- You have a phone system. A PBX, softswitch or contact-center platform that already handles calls and needs a route to the public network. It connects as a peer, usually from a fixed address, and its own dial plan, the rules that route its calls, does the call control.
- You have application code. You want your software to place or receive calls without running telephony infrastructure. You still need a trunk, and the thing that talks to it can be small: a softphone, a browser, the CLI, or a voice agent runtime. It authenticates with a short-lived session credential, a temporary username and password for a SIP client, rather than from equipment on a known address.
The distinction is about where call control lives, not about scale, and neither shape skips the trunk. What a light client saves you is running a phone system, not the connection itself. Bird's own tooling makes the point twice over: the dashboard's phone and the CLI's test call are both SIP clients placing real calls through one of your trunks.
Nor is the trunk an alternative to the API, because no endpoint places a call to a destination you choose. What is a voice API covers how the configuring half and the signaling half divide the work.
What does a trunk actually do?
It gives your equipment an address to send calls to, and decides which calls it will accept.
Bird assigns each trunk a fixed SIP domain, which is what you enter in your phone system so calls can be associated with the trunk. Your equipment sends to that domain on one of three transports: UDP or TCP on 5060, or TLS on 5061 when you want the signaling encrypted in transit.
A new trunk turns away every call. Both directions are off, and no sender is authorized. That is a deliberate default rather than an incomplete setup. A trunk that accepted calls the moment it existed would be a standing invitation, and toll fraud makes that expensive quickly.
Why are outbound and inbound configured separately?
Because they are different problems with different failure modes, and a trunk carries each direction on its own.
Outbound is your phone system placing calls through Bird. Until you enable it, the trunk refuses every outbound attempt regardless of credentials, so a correctly authenticated call still fails if the direction is off.
Inbound is Bird delivering calls to your phone system for the numbers that point at the trunk. Enabling it is not sufficient on its own: a trunk with inbound enabled and no delivery gateway refuses every incoming call to its numbers. Pointing a number at the trunk is done on the number rather than on the trunk, which is the other half people miss.
Turning inbound calling off puts every number pointing at this trunk back on reject, and turning it back on does not restore them. Deleting the trunk does the same. So the undo is not symmetric: if you disable inbound to test something, plan on re-pointing each number afterwards, and check the numbers rather than assuming the toggle restored them.
How does a trunk decide who may send it calls?
An IP allow list, API key authentication and session credentials decide it. They can be combined, and each becomes active as soon as it has one entry.
An IP allow list. Add the public addresses your equipment sends SIP from. Filtering starts the moment the list has one entry, and from then on only listed ranges may send calls. For equipment behind NAT this is the router's public address, not the phone system's private one. Calls from unlisted addresses are refused at the SIP layer and usually never reach the call log. An empty log is therefore a symptom of this rather than evidence that nothing was attempted.
API key authentication. Bird challenges the call, and your system answers with a hash of a password rather than the password itself. The hash is verified against a Bird API key that carries voice access at write level. In your PBX the username is always bird and the password is the key's secret. Like the IP list, it becomes exclusive as soon as one key is allowed.
Two operational details follow from that. Taking the voice permission off a key stops it authenticating immediately. The key stays in the trunk's allowed list, marked, so the list never reads as working when it is not. Putting the permission back restores it with nothing to change. Revoking or deleting the key is immediate on every trunk that allowed it, and it is permanent. Rotate by adding the new key to the trunk first, moving your equipment across, and revoking the old one last.
Session credentials. A short-lived SIP username and password answering the same challenge without exposing a long-lived secret. They are off on a new trunk, and they belong to the workspace rather than to one trunk. The password is returned only when it is minted.
Turning session credentials on does not change how allow-listed equipment connects. A call from a listed address on a trunk with no allowed API keys is still admitted with no password challenge at all. If you intended the credential to be the gate, the IP list is quietly still the gate.
Why does my browser or softphone fail to authenticate?
Almost always the digest algorithm. It is the one setting that fails in a way that looks like a credential problem.
By default Bird offers SHA-256 first and MD5 second, and your equipment answers with the first it supports. A trunk accepts only the algorithms it offers, so narrowing the offer narrows what can connect.
The trap is browsers: a browser answers with MD5 and nothing else. A trunk offering only SHA-256 rejects every browser call, which includes the dashboard's own phone. So keep MD5 in the offer on any trunk you intend to call from a browser, and reach for MD5-only when a PBX mishandles a challenge that begins with SHA-256. API keys work with either algorithm and never need reissuing when you change the offer.
So what do I set up?
- A trunk, whichever shape you are. Every call crosses one, so this step is not optional.
- A peer, if you run a phone system. Connect the PBX or contact-center platform from a fixed address, and let its dial plan control the calls.
- A light client, if you have application code. A softphone, a browser, the CLI or an agent runtime, authenticating with a short-lived session credential instead of a known address.
- One sender rule, whichever you chose. An IP allow list, an allowed API key or a session credential, remembering that each becomes exclusive as soon as it has one entry.
- MD5 left in the digest offer on any trunk you intend to call from a browser.
SIP trunks covers each setting and where to find it. SIP clients covers connecting a single client rather than a phone system, and voice troubleshooting works through calls that do not arrive.
In breve
Every path to the telephone network crosses a trunk.
What differs is the client on your side: a phone system connected as a peer, or a lighter SIP client such as a browser or the CLI on a short-lived credential.
A new trunk refuses everything.
Both directions are off, and there is no authorized sender until you add one. That is deliberate, not a setup step you can skip.
Each direction is enabled separately, and inbound needs a gateway.
A trunk with inbound enabled but no delivery gateway refuses every incoming call to its numbers.
Turning inbound off does not undo cleanly.
Every number pointing at the trunk goes back to reject, and turning inbound on again does not restore them. Re-point each number yourself.