An AI voice agent reaches the phone network over SIP (Session Initiation Protocol — the signalling that sets calls up and tears them down) plus a separate RTP (Real-time Transport Protocol — the stream that carries the audio) media path. Most agent "call problems" are not the model or the platform at all; they are ordinary SIP and media faults, and they repeat. This guide lists the ones that actually break agents, the symptom that identifies each, and how to fix it. It pairs with the setup walk-through in connect your AI voice agent over SIP (BYOC).
A useful habit first: separate signalling from media. If the call connects and then has no audio, the signalling worked and the problem is in the media path. If the call never connects or is rejected with a SIP response code, the problem is in signalling. That single split points you at the right section below.
On this page
One-way or no audio
The call connects, but one side hears nothing — or neither side does. Because signalling succeeded, the fault is in the RTP media path, and there are three usual causes. NAT (Network Address Translation — how a private network shares one public address) can advertise a private media address the other side cannot reach, so audio flows one way only. A firewall can block the UDP ports the return audio uses. And an SRTP (Secure Real-time Transport Protocol — encrypted media) mismatch, where one side encrypts and the other expects clear media, leaves each unable to decode the other. Fix it by giving the media its correct public address through NAT, opening the RTP port range, and making both ends agree on whether media is encrypted.
Codec mismatch (SIP 488)
A codec is the audio format the two sides use; if their offered formats don't overlap, the call cannot negotiate media and is typically rejected with 488 Not Acceptable Here. The fix is to make sure a common codec is on the table at both ends — G.711 is the widely supported baseline — and to avoid forcing a codec one side does not implement. Extra codec conversions in the path (transcoding) can also degrade quality, so prefer a shared codec end to end where you can.
DTMF doesn't register
DTMF (the keypad touch-tones a caller presses) can travel three ways: as RFC 2833 / RTP telephone-event packets, as SIP INFO messages, or inband inside the audio. Both ends must use the same method, and for RFC 2833 the payload type must match. If they disagree, presses are simply lost, which breaks menus and any capture your agent relies on. Agree on one method — RFC 2833 telephone-event is the common default — confirm the settings line up, and test with a few key presses.
Latency, jitter and robotic audio
Robotic, choppy or laggy speech is a network-quality problem, not a model problem. Latency (round-trip delay), jitter (variation in packet arrival) and packet loss all distort real-time audio, and they get worse when calls route to a distant region or pass through unnecessary transcoding. Agents are especially sensitive because they both listen and speak in real time. Reduce it by routing through a nearby point of presence, provisioning enough bandwidth, and cutting extra conversions from the path. Our network page describes the regional, failover-aware routing that keeps latency down.
Authentication and registration failures
If the call is refused before it connects, the trunk is not authenticating. With registered SIP credentials, a wrong username, password or realm returns 401 Unauthorized or 403 Forbidden; a registration that has expired stops new calls until it refreshes. With an IP allowlist, calls from an address that isn't on the trusted list are refused by design. Check the credentials, confirm the registration is current, or make sure your platform's SIP addresses are allowlisted on both sides. The two methods are compared in the BYOC guide.
Caller ID rejected
Outbound calls can be blocked or stripped when the agent presents a caller ID (the CLI — Calling Line Identification) it is not authorised to use, and rules differ by country. Present a number you are entitled to send — usually your own DID — rather than an arbitrary one, and expect some destinations to enforce their own CLI rules regardless. Keeping the presented number to one you control also means callbacks return to the right agent.
Calls fail under load
Everything works in testing, then calls fail at busy times. That is usually a channel limit — a channel is one concurrent call path — being reached, which surfaces as 503 Service Unavailable or calls that simply don't set up. Size concurrency to your busiest expected moment, not your average, and watch for automated outbound campaigns that spike well above normal. Velocity and channel limits also exist deliberately as anti-fraud controls, described on the security page.
SIP response cheat-sheet
A quick map from the response you see to where to look:
| Response | Usually means | Look at |
|---|---|---|
| 401 / 407 | Authentication required or failed. | Credentials, realm, registration. |
| 403 Forbidden | Not permitted — often an unallowlisted address or blocked CLI. | IP allowlist, caller ID. |
| 404 Not Found | The dialled number or route isn't recognised. | Number provisioning, dial format. |
| 480 / 486 | Unavailable or busy at the destination. | Endpoint state, routing target. |
| 488 Not Acceptable Here | No shared codec could be negotiated. | Codec offer on both ends. |
| 503 Service Unavailable | No capacity or a component is unavailable. | Channel limits, concurrency. |
Response codes describe where a call stopped, not who is at fault — use them to narrow the search, then confirm with a test call.