Audio and network
This page covers calls that connect but sound wrong (no audio, one-way audio, silence, delay, noise), with agents or in calls that never reach an agent, and the network problems that stop the agent application from reaching the voice servers. If calls don't reach the agent at all, or agents go to RONA, start with Agent calls and connection. If the problem is between your carrier or SBC and Graia CCaaS, see Telephony and SBC.
First, narrow it down
Who is affected tells you where to look:
| Who is affected | Most likely cause | Who fixes it |
|---|---|---|
| One agent | Headset, audio device selection, microphone permission, home network | The agent, with local IT |
| Agents in one office, or everyone on the VPN | Firewall, VPN or proxy on that network | Your network/IT team |
| All agents, on one channel or phone number | Your SBC or trunk | Your carrier or SBC provider – see Telephony and SBC |
| Callers, before any agent is involved (announcements, IVR menu, voice bot) | Workflow or voice bot settings, or the caller's carrier | Your workflow administrator – see Calls that never reach an agent |
| All agents, all channels, at the same time | A platform incident | Graia support – see Platform incidents and maintenance |
Then check the call recording, if your tenant records calls. If the recording has both the agent and the caller clearly audible, the audio reached Graia CCaaS in both directions and was lost after it left the platform: on the agent's computer or network, or on the caller's carrier side. A clean recording with a broken live call rules out the platform. For calls that never reached an agent, only the customer-leg recording exists, and only if your tenant records the customer leg. See Set up and test call recording for where to find recordings.
One-way audio or no audio
The call connects, but the agent can't hear the caller, the caller can't hear the agent, or neither hears anything.
Wrong headset or audio device selected
Most common cause for a single agent. The browser sends and plays call audio on the devices it has selected, which aren't always the headset the agent is wearing. This happens after a headset is plugged in, unplugged or docked, or when the computer has several audio devices (laptop speakers, monitor speakers, a dock, a headset).
Who fixes it: the agent.
- In Windows, open Settings › System › Sound and set the headset as both the output and the input device.
- In the browser's site settings for the agent site, check that the microphone is set to Allow and that the headset is the selected microphone.
- Close other softphone and calling applications completely, so they don't hold the headset.
- Reload the agent application and make a test call.
- If it still fails, try another headset, preferably a wired one.
Microphone permission
Without microphone access, the browser can't send audio, and the agent may not be able to answer at all. If the problem started right after a release, also load the latest version.
Who fixes it: the agent.
Follow the quick checks for agents: set the microphone to Allow in the browser and in Windows, and keep to one session. Then try another supported browser.
Trunk or SBC
When all agents on one channel or number are affected, or only agents who take calls in an external voice application such as Teams, the cause is usually outside the agent's computer: the trunk is down, an SBC returns an error, a firewall in front of a secondary SBC blocks the audio, or the phone system behind your SBC has a fault. See Telephony and SBC.
Calls forwarded to an external number are silent
If a workflow forwards a call to an external number before the call is answered, both parties can hear silence. Play an announcement first (this answers the call), then forward. See Workflows and routing.
Silence on the first call, or audio only after a few seconds
Typical reports: the first outbound call of the morning is silent until the agent retries or restarts the application, or two-way audio starts only after about 20 seconds.
Who fixes it: the agent, with local IT.
- Check the selected output and input device, as in Wrong headset or audio device selected. Headsets and docks that go to sleep overnight often come back as a different default device.
- Check the microphone permission.
- If several agents are affected at the same time, collect example calls (time, number, agent) and contact support. A trunk or SBC problem can also cause late audio – see Telephony and SBC.
Choppy, delayed or noisy audio
Crackling, gaps, robotic voice, echo or a delay of a few seconds.
| Check | How | Who |
|---|---|---|
| Is the recording clean? | If the recording is clean, the problem is on the agent's side or the caller's side, not in the platform | Supervisor |
| Right after a release? | Load the latest version of the agent application | Agent |
| Audio hardware | Try another headset or another computer. Clean recordings with bad live audio on one laptop pointed to that laptop's audio hardware | Agent, local IT |
| Network quality | Use a wired connection instead of Wi-Fi, close bandwidth-heavy applications, and test on another network (see Test the network) | Agent, network/IT team |
| VPN | Test without the VPN, or ask IT to send the Graia CCaaS addresses outside the VPN tunnel (split tunnelling) | Network/IT team |
| Trunk or SBC | If all agents on one channel, or only agents with an external voice application, are affected, see Telephony and SBC | Carrier/SBC provider |
For support to investigate, send example calls: the date and exact time, the caller's number, the agent, and whether it was inbound or outbound. "Calls are choppy" without examples can't be traced.
Bluetooth headset has no audio
A Bluetooth headset that is paired to several devices at once (for example a laptop and a phone) can switch to the other device, or keep the audio channel there. Teams or another calling application can also take the headset.
Who fixes it: the agent.
- Connect the headset to one device only, or turn Bluetooth off on the other devices.
- Close other calling applications.
- Reset the sound settings in Windows and select the headset again, as in Wrong headset or audio device selected.
- Test with a wired headset. If the wired headset works, the problem is the Bluetooth connection.
Calls that never reach an agent
Many calls end in the workflow: the caller hears announcements, uses an IVR menu or talks to a voice bot, and the call ends there. Agent headsets and networks play no part in these calls. The audio travels between the caller's carrier and Graia CCaaS, and between Graia CCaaS and the bot.
Who fixes it: your workflow administrator. For a custom or external voice bot, also the team or provider that runs the bot.
Find the call first
Calls without an agent appear in Conversation History, not in Task History. For each call you can:
- listen to the customer-leg recording, if your tenant records the customer leg. It runs from the start of the call to the end, so you hear what the caller heard and said.
- read the transcript. For voice bots, it includes the bot's speech-to-text transcript, with the bot's messages labelled AI.
- open the decision trace of a bot message to see what the bot did and how long each step took.
For support to investigate, send example calls: the date and exact time, the caller's number, the workflow, and the node where the problem happened.
Announcements and IVR menus
| Symptom | Where to look |
|---|---|
| An announcement doesn't play, or the old one still plays | Announcement upload fails or the old prompt still plays |
| An announcement is cut off | Announcement is cut off when the call is answered |
| Silence after the call is forwarded to an external number | Both parties hear silence after a redirect |
| Silence in the queue, for example before a callback offer | The queue treatment has no background music step. Add one, so the caller hears something while waiting |
| Silence while the workflow waits for an external system | A Custom integration node in sync mode keeps the caller in silence until the request finishes. Turn on async mode, play an announcement on the Meanwhile output, and continue with an Await node |
| The IVR ignores keypresses | The IVR doesn't recognise keypresses |
| Text-to-speech uses the wrong language or voice | The announcement voice comes from a customer language profile with Workflow TTS turned on, selected in a Set customer language node before the announcement |
Callers from one network hear nothing
If callers from one mobile network or one country connect but hear nothing, or their keypresses aren't recognised, and the customer-leg recording is silent or the call looks normal in the platform, the problem is usually with a carrier between the caller and Graia CCaaS. Collect example calls and ask that carrier to check. Audio cuts during IVR announcements can also come from your SBC or the phone system behind it – see Telephony and SBC.
Voice bots
Check the transcript first: it shows whether the bot heard the caller correctly. Most problems are settings on the Conversational bot node or in the customer language profile. Change one setting at a time and test.
| Symptom | Likely cause and fix |
|---|---|
| The bot doesn't understand the caller, or the transcript is in the wrong language | The bot needs the caller's language. Add a Set customer language node with a Voice Bot language profile on the path before the bot node. If several are on the path, the last one is used |
| Product names, IDs or local words are misheard | Add them to a key phrase vocabulary in the language profile |
| The bot answers before the caller has finished | End speech detection interval is too low. Raise it in small steps |
| Long pauses before the bot answers, and callers repeat themselves | End speech detection interval is too high. Lower it. Also check the decision trace: slow knowledge base searches or integrations add delay |
| The bot stops in the middle of a sentence | The caller (or a noise the caller made) interrupted it. Turn on Disable audio interruption if the caller must hear a statement in full |
| Callers can't interrupt the bot | Disable audio interruption is turned on |
| The bot moves on while the caller is still thinking | Customer silence timeout is too short |
| The call ends during the bot conversation, with an audio message | The workflow's maximum bot duration was reached |
The bot leaves through the Failed output | The bot couldn't answer, or had a technical problem with the AI model. Check the decision trace, and see Maximum output token limit reached |
| Wrong accent or voice | The voicebot speaks with the wrong accent or voice |
Background noise on the caller's side is filtered out automatically; there's nothing to configure.
Custom and external voice bots
- Custom voice bot (Custom Bot node): Graia CCaaS sends the conversation to your bot's WebSocket address. If the caller hears nothing from the bot, check in Integration › Voice bots that the WebSocket URL and API key are correct, and that your bot's server accepts the connection. The interruption and end speech detection settings are on the voice bot itself – see Custom Voice bots.
- External voice bot (External Voice Bot node): the bot is called on a phone number, over a SIP trunk.
- If the node exits on
Failed, the call couldn't be made: check the phone number and the trunk selection group. - If calls to the bot are answered and then drop within a second, or transfers from the bot back to your agents fail, the bot provider's trunk doesn't accept or reach every Graia CCaaS voice server. Graia CCaaS runs on active and passive voice instances, so the provider must be set up for both. Ask Graia support for the addresses and give them to the bot provider.
- If the node exits on
Phone number registration lost or softphone offline
Typical signs: a popup shows an error related to the phone number registration, outbound calls end immediately and go to wrap-up without ringing, the softphone status changes from Online to not found, or agents receive no calls and are put into RONA.
The agent application can't reach the voice servers. Causes, most common first:
- A firewall or VPN blocks the voice servers. Often it works without the VPN, on a mobile hotspot, or from home, and fails on the office network or the corporate VPN. Who fixes it: your network/IT team. Work through Network requirements for the agent application, for the firewall and for the VPN. If every agent at one site is affected and nothing changed on your network, see Every agent at one site is affected.
- A platform incident. If agents on different networks are affected at the same time, see Platform incidents and maintenance.
WebSocket connection errors
The agent application doesn't start, or keeps failing, on one computer or one network, and the browser console shows errors related to the WebSocket connection or the connection to the server.
The agent application uses secure WebSocket connections to the platform and to the voice servers. Something between the browser and the platform is blocking or closing them.
Who fixes it: the agent first, then your network/IT team.
- Test on another network. If the application works on a mobile hotspot, the cause is the original network.
- Disable browser extensions such as ad-blockers, privacy and security extensions for the agent site, or test in a browser profile without extensions.
- Check the proxy and firewall. WebSockets must not be blocked, inspected or timed out by a proxy or firewall, and the Graia CCaaS addresses and ports must be allowed (see below).
- Check DNS and certificates. The voice server names must resolve, and the browser must not show certificate errors for them. A proxy that replaces certificates (TLS inspection) can break the connection.
- Check the VPN. An unstable VPN causes repeated disconnects. If the connection drops for more than 3 minutes, the agent is logged out – see Agent auto-logout mechanism.
If an agent gets an error related to connecting the user, see Agent can't connect to the phone: a blocked connection is one of the causes there.
Network requirements for the agent application
Give this section to your network/IT team when you set up a new site, a new firewall or a VPN. The agent application runs in the browser: it uses the web addresses agent.graia.ai and portal.graia.ai, plus secure WebSocket connections to the Graia CCaaS voice servers.
Make sure that:
- The Graia CCaaS addresses and ports are allowed in the firewall, web filter and VPN. Ask Graia support for the list for your tenant.
- WebSockets aren't blocked by the firewall, proxy or web filter, and aren't cut by short idle timeouts.
- VPN users have the Graia CCaaS addresses excluded from the tunnel (split tunnelling), or a stable VPN connection.
- The browser isn't put to sleep. Disable sleeping tabs and tab throttling for the agent site – see Agent auto-logout mechanism.
Webchat customers who start a web call from your website only need normal web (HTTPS) access and microphone access – see Web calls.
Webchat widget doesn't work on your website (Content Security Policy)
The widget appears but nothing happens when a visitor clicks Continue, buttons look wrong, or the widget doesn't load. The browser console on your website shows a Content Security Policy error that names the connect-src directive.
Your website's Content Security Policy (CSP) only allows connections to the addresses it lists. The widget connects to the Graia CCaaS chat service over a WebSocket, and the policy blocks it.
Who fixes it: your web team.
- Open your website, press F12, and look for CSP errors on the Console tab. The error names the blocked address and the directive.
- Add the address that the console names to the
connect-srcdirective of your website's policy (and toscript-src,style-srcorframe-srcif the console names those). It's the same chat service address that appears in the widget code you copied from the portal. - Also check Trusted Domains on the webchat channel's Widget configuration tab: if it's turned on, your website must be in the list.
For other webchat problems, see Email, chat and messaging.
Test the network
Use these tests to show whether a problem is on the network, and to give your IT team something concrete.
- Try another network. Connect the same computer to a mobile hotspot and log in again. If the problem is gone, the original network (Wi-Fi, office firewall, VPN, proxy) is the cause.
- Test without the VPN, if your policy allows it.
- Test the ports. In Windows PowerShell, run
Test-NetConnection <host name> -Port <port>for each address and port on the list from Graia support.TcpTestSucceeded : Truemeans the port is open. - Test DNS. Run
nslookup <host name>. If the name doesn't resolve, or resolves differently on the office network and on the hotspot, check your DNS servers and filters. - Check Wi-Fi against a cable. If it works on a cable but not on Wi-Fi, the wireless network or its firewall profile is the cause.
- Collect logs while it fails. If you still need support, download the debug logs right after a failed call, attach them to your support ticket, and include the public IP address of the network.
Related
Was this page helpful?