Connecting a Voice Agent to Turkish Telephony: SIP and Numbers

Voice agent documentation usually starts with the same step: buy a phone number from the dashboard. One click, a number arrives, the agent dials and the demo works.

In Turkey that step does not exist. Platform inventories either carry no Turkish numbers or carry them in a form that regulation and allocation make impractical, so you stall on step one.

The solution has a name: bring your own number. In English documentation it usually appears as a footnote, and here it is the main road rather than the exception.

What the setup actually looks like

The chain has four links, and each one belongs to a different party, which is why the setup takes days rather than minutes.

1. 1.The number stays with your operator in Turkey: a fixed line, a geographic number or your existing exchange number
2. 2.The operator gives you a SIP trunk: server address, username, password and port
3. 3.You configure those details on the voice agent platform, which then places calls through your operator
4. 4.On outbound calls the caller ID appears as your own number

The result is a split that works well in practice: the AI runs abroad, the voice traffic passes through your line, and the customer sees the number they already know.

Reading that table before the first call saves most of the debugging. Three of the four rows belong to somebody outside your team, and each one has its own lead time.

Caller ID does not show, or shows wrongly

This is the most common failure. An operator will not carry a number as caller ID unless that number belongs to their network, and refusing is the correct behaviour rather than an obstacle.

If they did otherwise, caller ID spoofing would be trivial for anyone with a SIP account, so the restriction protects your brand as much as it inconveniences your setup.

What you need is confirmation that the number is authorised on that SIP account. Saying the number is ours is not enough; the trunk itself has to be permitted to originate it.

Latency arrives from four places at once

In a voice agent, latency is not a detail of quality; it is quality. Once the gap after the caller stops speaking passes about a second, the conversation stops feeling natural.

At two seconds the other side says hello into the silence, which is the point where the call is effectively lost regardless of what the agent says next.

The hard part of running a voice agent here is not the model. It is the telephone, and the telephone has an owner who is not you.

• Audio travelling from your line to the platform, where geographic distance enters the picture
• Turning speech into text
• The language model producing an answer
• Turning the answer back into audio and sending it home

If you connect from Turkey, the first item adds a real burden on a setup hosted in the United States. Choosing a European region, where the platform offers one, is usually the single largest improvement available.

Where the rest of that delay comes from, and what can be done about each part, is covered in the article on voice agent latency.

Codec and audio quality

A phone line is narrowband. Speech recognition models are generally trained on wideband audio, and the gap between the two explains a familiar disappointment.

An agent that performs perfectly in a studio stumbles on the phone, and nothing is broken; the input simply lost the frequencies the model relies on.

The remedy is not switching models but setting expectations correctly: test at phone quality and evaluate on phone recordings, because microphone tests create a false sense of success.

Why microphone tests mislead

A laptop microphone captures the exact frequency range the phone line removes. Every consonant the model needs is present, so the test passes and production fails.

So the acceptance test has to run on the channel that will carry the traffic. A recording from the actual line is the only evidence worth trusting before a list is loaded.

The concurrent call limit nobody reads

Your SIP trunk carries a limited number of simultaneous calls and that limit is written in your contract. It rarely comes up until a campaign starts.

When the queue does not know the limit, part of the calls fail silently. Nothing errors visibly; the campaign simply produces fewer conversations than it should.

The queue's concurrency ceiling should be set below the line's capacity. Pushing against the ceiling also affects real customer calls arriving on the same trunk.

Leaving headroom is not caution for its own sake. A trunk saturated by an outbound campaign drops the inbound calls you were paying to receive, which is the most expensive way to fail.

Inbound calls are a separate project

Most teams that finish the outbound setup assume inbound will work by itself. It will not; routing is configured separately and has its own failure modes.

The decision to make is whether an inbound call drops straight to the agent or sits behind an option in your existing menu. The second is a much safer start.

It is safer because the existing flow stays intact, the agent sits behind one specific key, and you widen its scope only as it proves itself.

The order that works

The sequence below is not a preference. Each step verifies the one before it, so a failure is always local rather than a hunt across the whole stack.

1. 1.Get the SIP details and confirm the number is authorised on that account
2. 2.Connect and call your own mobile; you are testing the trunk, not the agent
3. 3.Confirm from the receiving end that caller ID appears correctly
4. 4.Attach a simple greeting and measure the latency
5. 5.Set up answering machine detection before spending on a list
6. 6.Fix the concurrency ceiling below your line capacity
7. 7.Only then run a real list

Each step verifies the one before it. Skipping the order produces a familiar picture: the system works, some calls drop, some talk to voicemail, and nobody can say why.

Answering machine detection belongs here rather than later because every undetected voicemail burns all four cost items, as covered in the article on cost per minute.

The language side of the same setup has its own list of problems, covered in the article on Turkish speech recognition.

What this comes down to

The hard part of running a voice agent here is not the AI; it is the telephone. The model side is an API call, while the line side needs conversations with an operator.

It also needs authorisation and measurement, neither of which appear in a platform's quick start guide, and both of which decide whether the thing works on a Monday morning.

How much of this you should carry yourself is a separate decision, covered in the article on building versus buying.