A trunk is the least glamorous component in a voice deployment and the one most likely to decide whether it works.
It is a standing agreement between two systems about who may send calls, how many at once, and in what audio format, and almost every mysterious problem on a new agent line traces back to one of those three clauses being wrong.
- A trunk is a relationship, not a cable Two systems agree in advance who may send calls to whom, how many at once, and in what format.
- Identity is proved two ways Either the trunk logs in with credentials or it is trusted because of the address it comes from, and mixing the two causes most rejections.
- Concurrency is a hard ceiling Channels are provisioned in advance, and when they are exhausted new callers are rejected rather than queued.
The word survives from an era of physical bundles of copper. What it means now is a configured relationship between two endpoints over an IP link, with an agreed limit on simultaneous conversations and an agreed way of proving identity.
It matters for agents specifically because organizations rarely start empty. The phone estate already exists, the extensions already work, and the agent has to join it rather than replace it. The trunk is the joint where that happens.
What a Trunk Actually Is
Strip away the history and a trunk is a configured, persistent arrangement between two telephony endpoints. One will offer calls, the other will accept them, and both have agreed in advance on the terms under which that happens.
- An address on each side, so each knows where to send call offers and where legitimate ones come from.
- A method of proving identity, so neither end accepts calls from a stranger claiming to be the other.
- A ceiling on simultaneous conversations, provisioned rather than discovered at peak.
- A list of acceptable audio formats, ordered by preference, that the two ends pick from per call.
- A convention for how the dialed number is presented, since the two sides may format numbers differently.
Nothing in that list is exotic, and all of it is negotiated before a caller is involved. When a trunk misbehaves it is nearly always because one of those five clauses was assumed rather than agreed.
For an agent deployment the trunk normally faces an existing private branch exchange, a session border controller or a contact center platform. The agent is presented as another destination that estate can send calls to, which is why the surrounding extensions and dial plans keep working unchanged.
The most useful mental model is a standing invitation with conditions attached. A trunk does not carry anything by itself. It describes the terms under which one side will accept a call offer from the other, every time, without renegotiating the relationship.
How a Trunk Proves Who It Is
Two approaches dominate, and they behave quite differently in operation. Choosing one and then half-configuring the other is the single most common cause of calls being refused on a brand new trunk.
One side registers with a username and secret and keeps that registration refreshed. Its address can change freely, since identity travels with the credential.
Each side lists the addresses it will accept offers from. Nothing logs in, which is simpler to reason about but brittle whenever an address changes.
A rejection looks identical from the caller's side either way: the call simply does not connect, with no clue about which clause was violated.
Address based arrangements are common between two fixed systems inside a controlled network. They break in exactly one predictable way, which is that an address changes without telling the other side, and calls stop the moment they do.
Credential based arrangements survive address changes but introduce a dependency on the registration staying alive. A lapsed registration produces an outage that looks like the far end has vanished, and it usually recovers on its own, which makes it maddening to diagnose after the fact.
Either way, the credential or the address list is a security control and not merely a setting. An unrestricted endpoint is an invitation to send calls through another organization's estate, and both sides should treat the configuration with the care that implies.
Channels: How Many Calls the Trunk Will Carry at Once
Capacity on a trunk is counted in simultaneous conversations, often still called channels. The number is provisioned in advance, and it is a genuine ceiling rather than a guideline.
What happens at the ceiling is the part worth understanding. A call arriving when every channel is busy is refused, not held. The caller hears a failure tone or is diverted somewhere, and no queue forms on its own.
Sizing this for an agent is different from sizing it for a team of people. A staffed line self-limits, because nobody answers a call there is no person for. An agent will happily accept everything offered to it, so the trunk becomes the only thing setting the limit.
| Situation | Effect on simultaneous calls | What to provision for |
|---|---|---|
| Steady inbound enquiries | Predictable, follows normal business hours | The busiest hour, not the daily average |
| An outage or a mailshot | Arrivals cluster tightly rather than spreading out | Headroom above the worst historical spike |
| Outbound running alongside inbound | Both directions consume the same pool unless separated | Separate allocation, or a reserve held back for inbound |
| Calls transferred to staff | A transferred call can hold two legs at once | Counting the transfer overlap rather than one leg per call |
| Retries after a failure | Failed attempts return and compete with new arrivals | A backoff that does not amplify the original incident |
The transfer row surprises people. During a handover both the original leg and the new one exist at the same time, so a deployment doing many handovers consumes more capacity than a simple count of calls suggests. What that handover involves is set out in how a live call is handed to a person.
Codec Negotiation and What Gets Agreed at Setup
Before audio flows, the two ends have to agree how it will be encoded. Each offers a list in preference order, the other picks from it, and the highest common choice wins.
Most telephone traffic settles on a long-established narrowband format, because it is the one thing every system supports. Wideband formats sound noticeably better and are agreed only when both ends offer them and nothing in between forces a downgrade.
Voice agents are more sensitive to this than people are. Speech recognition works from the same audio the caller produced, so anything the format discards is discarded before recognition ever sees it. Unusual names, spelled letters and strings of digits suffer first.
Transcoding and Why It Is Worth Avoiding
When the two ends cannot agree, something in the middle converts between formats. That conversion costs a little delay, costs some quality, and adds a component that can fail independently of either endpoint.
It is not always avoidable, particularly where an agent joins an older estate. It is always worth knowing about, because a trunk that quietly transcodes every call is a fixed tax on quality that no amount of tuning above the network will recover.
One category deserves separate attention: keypad tones. How digits pressed during a call are represented is negotiated alongside the audio format, and getting it wrong makes menu input unreliable in ways covered by handling keypad input during an agent call.
What a Misconfigured Trunk Looks Like
Trunk faults have recognizable shapes. Matching the symptom to the clause that was violated saves a great deal of time, because the alternative is escalating a vague quality complaint to three vendors at once.
| Symptom | Clause usually at fault | Where to look |
|---|---|---|
| Every call refused immediately | Identity, or the number style expected | Whether offers are arriving at all, and what is sent back |
| Calls connect, then silence in one direction | The audio path, not the signalling | Which side sends audio and whether anything blocks the return |
| Calls drop at a consistent moment | A keepalive or session timer neither side is refreshing | Timer settings on both ends, and any device between them |
| Busy signals during peaks only | Channel ceiling reached | Simultaneous call counts at the busiest hour |
| Audio audibly worse than expected | Format agreement or conversion in the middle | What the two ends offered and what was actually chosen |
| Keypad presses ignored | Digit representation mismatched between ends | How tones are carried on this trunk specifically |
The consistent-drop row is worth calling out. When calls end at roughly the same point every time, the cause is almost never the conversation. Something is expecting a periodic refresh it is not receiving and tidies the session away on schedule.
Symptoms that look like trunk problems but are not usually involve timing rather than transport, and separating the two is set out in which layer owns each part of the call path.
Provisioning a Trunk for an Agent That Never Sleeps
A trunk built for a staffed team carries assumptions that stop being true when software answers. Working through these before launch avoids a class of incident that is very hard to reproduce afterwards.
- Agree the identity method once, in writingPick credentials or addresses, record which, and make sure both ends are configured for the same one rather than partly each.
- Size channels against peaks and overlapsUse the busiest hour, add the transfer overlap, and keep headroom for the day everybody calls at once.
- State the format preference explicitlyKnow what both ends offer, which one calls actually settle on, and whether anything in between is converting.
- Test digits, transfers and long callsShort happy-path calls pass on almost any trunk. Timers, keypad handling and handovers are where real configuration faults surface.
- Decide what happens when the trunk is unavailableCalls should land somewhere defined rather than failing silently, and that path should be tested rather than assumed.
The last step is the difference between a controlled degradation and a day of missed calls nobody noticed. Where that fallback should point and how the condition is detected are covered in detecting failure and recovering safely.
It is also worth rehearsing these cases before the number carries real traffic, using the approach in testing a voice agent before and after launch rather than discovering them from customer complaints.
Conclusion
SIP trunking connects AI voice agents with existing business phone systems, but a stable deployment depends on more than establishing a connection. Authentication, concurrent call capacity, codec compatibility, media routing, and failover behavior all need to be checked together.
Before launch, confirm each side's trunk settings, test peak traffic and call transfers, and verify real-world audio, keypad input, long calls, and outage handling. These checks help ensure the voice agent stays reliable when customer demand changes.
Frequently Asked Questions
Not always. A trunk is the usual answer when an organization already runs its own telephony and the agent has to join it. Where numbers are bought fresh from a communications provider, the provider handles that side and the connection is made through its own interface instead. Existing estates are what make a trunk the natural choice.
Enough for the busiest hour rather than the daily average, plus headroom. Two things push the number up: automation removes the staffing ceiling that used to limit simultaneous calls, and every transfer briefly holds two legs at once. Count the overlap, then leave room for the clustered arrivals that follow an outage or a campaign.
Most often the two ends disagree about identity or about how the called number should be written. One end may expect a registration while the other relies on a trusted address, or one sends a national format the other does not recognize. Both look the same from the caller's side, so check what the receiving end sends back.
The call setup succeeded and the audio did not follow the same route. Typically something between the two ends permits the signalling messages but blocks or misdirects the media, or one side is sending audio to an address the other never reaches. Establish which direction fails first, because that narrows it very quickly.
Yes, more than it affects a human listener. Recognition works from the audio as delivered, so anything the format discarded is gone before any speech software sees it. Spelled names, reference codes and strings of digits are the first things to suffer, which is why the chosen format is worth confirming rather than assuming.
