A SIP trunk is the connection between a phone system you run and a carrier network. If you have a PBX, a session border controller, a contact-centre platform or any other SIP equipment, the trunk is how its calls get to the outside world and how outside calls get to it.
The first question is usually whether you need one at all, and the honest answer for a lot of people is no.
Do I actually need a trunk?
Only if you have SIP equipment to connect.
There are two ways to make calls happen, and they suit different shapes of problem:
- You have a phone system. A PBX, softswitch or contact-centre platform that already handles calls and needs a route to the public network. That is what a trunk is for, and there is no way around it.
- You have application code. You want your software to place or receive calls without running telephony infrastructure. Then the voice API is the path, and you never create a trunk.
The distinction is about where call control lives, not about scale. A large operation with an existing PBX wants a trunk; a small service placing a handful of programmatic calls should not have to stand up a phone system just to use one.
If you are connecting a single softphone rather than a phone system, that sits between the two: it registers as a client against a trunk, which is why the trunk's authentication settings still matter to you even without a PBX.
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.
Then there is the part people underestimate. A new trunk turns away every call. Both directions are off, and no sender is authorised. 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 the toll fraud economics make 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.
One behaviour here is worth knowing before you touch the setting rather than after. 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?
Three mechanisms, which 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 at all, which is why an empty log is 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, 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 matter more than they look. Taking the voice permission off a key stops it authenticating immediately while leaving it 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 is permanent, so 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, belong to the workspace rather than to one trunk, and the password is returned only when it is minted.
The interaction to be deliberate about: turning session credentials on does not change how allow-listed equipment connects, and 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, and 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.
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.