VICIdial audio, transfer and disposition problems

The call connects, so the signaling works, but the audio does not reach the other side. Common reasons are a firewall that blocks UDP between your dialer and the bot server addresses the team gave you, a SIP peer that is not set to G.711 u-law only, and missing NAT settings on the peer. On the VoiceOI side, the bot server may be unable to pass the person’s voice to speech recognition: only the team can check that.

In Call Logs, Bot Said lines with no User Spoke lines, and a call that ends as DAIR, fit this entry.

Compare with a call a person on the same campaign takes over the same carrier. If the person hears the caller, the carrier leg works. Ask your admin whether the firewall changed recently.

Your administrator allows UDP in both directions between the dialer and the bot server addresses. Ask the team to check the bot server, and the peer on your dialer with your administrator. Do not edit the peer yourself.

Bot Said lines with no User Spoke lines mean the bot hears nothing: the script reprompts into silence, and the call usually ends as DAIR, or as AM in a pre-recorded script. Either the person’s voice does not reach your Asterisk (a carrier-leg fault), or it does not reach the bot server.

User Spoke lines where the person says “hello” more than once, with the person reporting silence, mean the bot’s voice does not reach the person. A common reason is NAT or a firewall blocking the bot’s audio on its way back to your dialer.

Compare a call a person takes on the same campaign. Silence there too means the carrier leg, which you fix with your carrier.

Ask your admin which Asterisk server placed the call, and whether its bot peer has the NAT settings in SIP settings.

Ask the team to check the peer on that server with your administrator, and the bot server. For many DAIR calls, see Many calls end as DAIR.

Common causes are packet loss or jitter between your dialer and the bot server, which breaks audio in either direction, and a busy dialer: if your carrier leg uses another codec than G.711 u-law, your Asterisk may have to convert the audio, which adds load.

A synthetic voice that is not broken is a voice choice: see Voices, audio and the Simulator.

Play the same line in the Simulator. If it sounds clean there and breaks up on calls, the voice is not the cause: look at the network path and the servers.

Note whether it happens on every call or at busy times, and on every Asterisk server or one.

Your administrator checks the dialer’s load and the network path, and keeps the bot peer on G.711 u-law only. The team checks the bot server’s load for the same minutes.

Common causes are a server with different NAT settings, a different firewall or a bot peer that differs from the others: the calls connect when every server is on the allow-list, but that server carries no audio. Refused calls are a different case: see Some calls work and some are refused.

Ask your admin which server placed each good call and each bad call, and to compare the bot peer and route on a good server with those on a bad one.

The team matches the peer and the route on every server that places bot calls, with your administrator. Your administrator checks that each server’s firewall allows UDP to the bot server addresses.

The dialer refused the hand-off, or VICIdial could not carry it out, depending on the transfer method of the step.

With SIP Blind Transfer (REFER), your dialer answers with a SIP code such as 403, 404, 481 or 603. It can be the reply to the REFER or, from a dialer that accepts the request first, a status message after it.

With ViciDial Native API Transfer (Instant Release), VoiceOI asks VICIdial’s agent API to move the call, and there is no SIP code. It fails when the API user lacks Agent API Access, the bot’s remote agent entry is not Active, the bot route does not pass the call code header, the destination is not a full number that dials through your dialer’s default context (the team confirms the form during onboarding), or, with two VICIdial servers, the request goes to a guessed one. If VoiceOI cannot work out the bot line or the lead, it sends a REFER instead.

Or the Transfer Call step has no destination. Then nothing is sent and the call ends at that step: see The transfer step does nothing.

Read the transfer method on the Transfer Call step (in the AI Voice Agent editor, Transfer method on the Handoff tab). Ask your admin whether the dialer’s SIP log shows a REFER at that time and every answer to it (SIP debugging may need to be on, limited to the bot peer and switched off again after one repeat test call). Only that log shows a failure reported after a first “accepted”.

For a REFER, ask your admin to check three things: the bot peer allows transfers and names a context for them (see SIP settings), the destination exists in that context on the server that placed the call, and the call was still up when the REFER went out (compare the time with calls in Call Logs where the person hung up).

For a REFER, fix what the log names, then place a test call.

For the Native API method, your administrator confirms Agent API Access is 1 on the API user (see What does the VICIdial API user need?) and that the destination dials through the dialer’s default context, you check that the bot is Active (START did nothing), and the team checks that the route passes the call code header.

Your dialer’s SIP log shows a 403 for the transfer. In SIP, a 403 means the dialer understood the request and refused it. The reason text next to the code may say more.

Ask your admin for the REFER and the dialer’s answer in the SIP log, and for the bot peer as it is now. Compare it with the example in SIP settings: a peer that was rewritten or restored from an older copy can lose its transfer lines.

If the peer lost its transfer lines, the team restores them with your administrator, who reloads the SIP configuration. Then place a test call that qualifies and check that it reaches the in-group.

Your dialer’s SIP log shows a 404 for the transfer. In SIP, a 404 means the destination was not found. It is your dialer’s answer to a transfer request, not the 404 the bot server sends when a call arrives with no script, lead or campaign: see connection troubleshooting.

Read the destination in the Transfer Call step (Destination Phone Number) and look for a typo. The REFER goes back to the address the call came from, so ask your admin whether that extension exists in the transfer context of the bot peer on the server that placed the call. In a cluster it must exist on every server that places bot calls.

You correct a mistyped destination in the step, save, and press Force bot sync on Integrations.

If the extension is missing on a server, your administrator adds it with the team.

Your dialer’s SIP log shows a 481 for the transfer. In SIP, a 481 means the call the request refers to does not exist (any more). The reason text next to the code may say more.

Get the times of the 481s and compare them with calls in Call Logs where the person hung up just before the hand-off.

If 481 appears when the person stayed on the line, send the times to the team, which checks the call with your administrator.

Your dialer’s SIP log shows a 603 for the transfer. In SIP, a 603 means the dialer declined the request. The reason text next to the code may say more.

Ask your admin to read the reason next to the REFER in the dialer’s SIP log, and to check the peer and the destination as in the 403 and 404 entries.

Fix what the log names. If it does not explain the 603, send the log lines to the team, which checks the peer with your administrator.

A Transfer Call step with no destination sends no hand-off. The script ends at that step, so VoiceOI hangs up on the caller. The call is not coded XFER: the lead normally shows HANGUP unless the step sets another Vicidial Disposition. The field is Destination Phone Number for SIP Blind Transfer (REFER), Dialplan Extension or Target Number for ViciDial Native API Transfer (Instant Release), and Transfer target in the AI Voice Agent editor. Direct IP to IP and ViciDial AXFER (Native) hide the field, and neither is supported on the VICIdial path.

In Call Logs, look for a Transferring line that names the destination. Without it, no hand-off was sent.

Open the step and read Transfer Mode and the destination.

You set the mode to ViciDial Native API Transfer (Instant Release) or SIP Blind Transfer (REFER) (in the AI Voice Agent editor, “ViciDial Native API (instant release)” or “SIP blind transfer (REFER)”) and enter the destination the team gave you. Save and test.

The call reached your dialer’s in-group, but VICIdial had no closer to give it to. The reasons are no closer signed in and ready in that in-group, an in-group that is not allowed for the campaign your closers are logged into or that they are not set to take calls from, and all closers busy. VICIdial, not VoiceOI, chooses the closer.

In the live agent view in VICIdial’s admin, look at the in-group: are closers signed in, ready, and in that in-group? Ask your admin whether the in-group is allowed for the campaign your closers are logged into.

You sign your closers in before the campaign starts.

Allowing the in-group was part of the team’s onboarding. Ask the team to confirm it, and ask your administrator whether your closers take calls from that in-group.

The destination in the step decides the in-group, because your dialplan routes that extension or number to one in-group. A script with several transfer steps can reach a different step than you expect. Routing steps such as the Matrix Router may not run on bots that take calls through VICIdial: see The call ends when it reaches the ZIP Resolver or the Matrix Router. Which closer inside the in-group takes the call is VICIdial’s decision, not VoiceOI’s.

In Call Logs, read the Transferring line. It names the destination used. Compare it with your dialplan.

You correct the destination in the step. Your administrator changes how the in-group picks a closer.

With SIP Blind Transfer (REFER), VoiceOI can also send a follow-up transfer request to VICIdial for the same call. Only the team can see which requests were sent for a call.

Note the time of the call and the transfer method of the step.

Send the details below to the team, which can change how that transfer is sent.

After the hand-off the bot is no longer on the call, and the audio travels through your VICIdial and your carrier, which VoiceOI cannot affect. Common reasons are the closer’s phone or softphone, and NAT or a firewall on the carrier leg.

Does it happen on other calls into the same in-group, such as calls your own agents transfer? Does it affect one closer or all?

Your administrator fixes the closer’s phone or the carrier leg in VICIdial. If other calls into the in-group have audio, ask the team to confirm when the hand-off was sent and to what destination.

Before a transfer, VoiceOI writes the notes into the lead’s Comments through VICIdial’s API. If the write fails, the closer sees the earlier value. It fails when the API user cannot change leads or the bot server addresses are not allowed on your web server: see Test connection passes, but statuses and notes never reach VICIdial. With two VICIdial servers, VoiceOI refuses the write when it cannot tell which one the call belongs to: see I have two VICIdial servers.

Other reasons: the step has no notes set (Notes for the closer is empty), the AI agent left the note out (a blank Comments instruction does not switch notes off), the call has no lead ID (see No status reaches VICIdial), or the closer’s screen does not show Comments. For closers on a separate VICIdial, Also send the notes to a closer dialer must be on: see Notes for the closer.

Open the lead in VICIdial and read Comments. Notes there mean VoiceOI wrote them, and the problem is what the closer’s screen shows. Empty or old text means the write failed. Then look at Notes for the closer on the Transfer Call step.

You add the details to Notes for the closer, or, for an AI agent, describe in the Comments instruction what the note must always contain. For a failed write, follow the entries linked above: your administrator fixes the API user, and the team checks the dialer match.

Comments in VICIdial holds 255 characters. For Notes for the closer, VoiceOI shortens long free-text answers first, then drops whole details from the end, and avoids cutting a word in half. It also converts the notes to plain ASCII (accents are removed from letters and other special characters are dropped) and replaces a | inside an answer with /.

In the AI Voice Agent editor, the agent writes the Comments itself, and VoiceOI cuts them at 255 characters, which can fall in the middle of a word.

Compare the preview in the editor with the lead’s Comments in VICIdial. A missing last detail fits the first case.

You put the details the closer needs first in the list, because the last ones go first. Shorten the labels (up to 40 characters) and remove details you do not use. For an AI agent, write the Comments instruction so the note lists the most important facts first and stays short.

VoiceOI writes to a lead, so the call must carry a lead ID. A call dialed straight to the bot’s extension, such as a softphone test, usually has none, and VoiceOI then skips the status and call log writes. The same happens when the bot route does not pass the lead.

If calls from a campaign also write nothing, the cause is the link to your VICIdial API, such as a read-only API user or a connection that is Switched off: see Test connection passes, but statuses and notes never reach VICIdial.

Compare a call from a campaign list with a call you dialed to the bot directly.

Test from a campaign: put a lead with a number you control in a test list and let the campaign dial it (How do I check that it works?). If campaign calls also write nothing, ask the team to check that the bot route passes the lead.

VICIdial accepts a status only if the campaign’s status list has it. For any other, the lead keeps the status it had, so one code can be missing while the others arrive. Which status codes does VoiceOI write? lists them all.

Call Logs and Dialer Dispositions show the code VoiceOI chose, not VICIdial’s reply. The code warning on the Outcomes tab checks a short list of common codes, not your campaign.

List the codes you see in Dialer Dispositions, and ask your admin to compare them with the statuses the campaign can use in VICIdial. Look at the lead for one call of each missing code.

Your administrator adds the missing statuses to the campaign. VoiceOI cannot do it for you.

Or you change the step’s Vicidial Disposition, or the AI agent’s outcome code, to a status the campaign has.

In VoiceOI’s experience, VICIdial leaves a remote agent call at XFER in its call log until another status replaces it. VoiceOI finds the entry with the call code that the bot route passes in the X-VICIdial-CallerID-Code header, and sends the campaign with it. Without a valid code, with no campaign on the call or the connection, or with an API user that cannot change leads, VoiceOI may not be able to update the entry, so the lead’s status can be right while the call log still says XFER. VoiceOI writes the entry a few seconds after the call, so check a minute later.

Compare the lead’s status with the call’s status in the call log. A right lead status and an XFER call log fit this entry. Ask the team to confirm that the route passes the call code header.

The team repairs the header in the bot route with your administrator. The example route is in What is the dialplan hook?. A line that stays on a call is a different problem: see A remote agent line stays INCALL.

For a transferred call, the status goes to VICIdial with the transfer request (or just after it, for a REFER), and VoiceOI writes nothing afterwards. If that request fails, the lead keeps the status VICIdial gave it. The code is the Vicidial Disposition on the Transfer Call step, or XFER if none is set. An earlier AM or DNC on the call stays in place of it.

After the hand-off, your closer’s own disposition normally replaces the status in VICIdial, while VoiceOI keeps the bot’s code.

If the transfer never started, VoiceOI changes XFER to HANGUP. A transfer that your dialer refused still counts as XFER in VoiceOI: see The bot says “connecting you now”.

Open the Transfer Call step and read Vicidial Disposition. Ask a closer how they dispositioned the call.

You set Vicidial Disposition on the step to the status you want. The statuses closers can pick are your administrator’s to control in VICIdial.

The subtitle of Dialer Dispositions reads “Real-time breakdown of disposition statuses directly from the dialer.” The page does not read your dialer. It counts VoiceOI’s own records of the calls its bots took, with the code VoiceOI chose.

So the two differ when a status VICIdial dropped still counts in VoiceOI, when a closer changes the lead afterwards, when a refused transfer is counted as XFER, and when VICIdial counts dials that never reached a bot. VoiceOI counts calls by when they started, and its calendar windows such as Today follow the time zone set in Settings. Reports built from VICIdial’s agent log can differ from the call log.

Pick one day and one campaign, with the same time zone and date range on both sides. Compare ten calls by lead ID between Call Logs and VICIdial’s call report.

Use VoiceOI for what the bots did, and VICIdial for the state of the leads and the closers’ results. For a code missing in VICIdial, see Some statuses never appear on leads.