Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 17 Next »

The Sharpen platform is built to work with the equipment you have with minimal intervention, but sometimes software privacy and access settings, network interruption, or something else along the way can interrupt your experience. This set of guides helps guide you along the troubleshooting path. Based on the symptom experienced, follow the link to common solution which applies

Symptoms

Sharpen Q phone shows as “Disconnected”

If your microphone is not known or configured by your operating system, your web browser will not have access, and thus, Sharpen will not have access to your microphone. Similarly, if your web browser or OS privacy settings do not allow access to the microphone, Sharpen will not have access. In this situation, Sharpen Q will attempt to place a call, but upon failed attempt to reach an audio input device, the call will fail.

Potential Causes

Common Solutions

  • Microphone not available or plugged in

  • Microphone not allowed by browser or OS privacy settings

  • Sharpen Q phone not connected to Sharpen WebRTC infrastructure

  • Validate physical connection of headset or microphone

  • Validate/update audio driver for device handling microphone

  • Choose appropriate audio device for mic input from OS input chooser

  • Allow access to microphone through OS for specific apps

  • Allow access to microphone through browser for specific pages

  • Validate/set the appropriate microphone in browser

  • Validate ports necessary for WebRTC are open

  • Work with SharpenCare to confirm healthy operations of WebRTC and Voice Processor infrastructure

Applicable guides

Cannot place or connect a call. Interface shows “connecting” followed by a failure to connect

If your microphone is not known or configured by your operating system, your web browser will not have access, and thus, Sharpen will not have access to your microphone. Similarly, if your web browser or OS privacy settings do not allow access to the microphone, Sharpen will not have access. In this situation, Sharpen Q will attempt to place a call, but upon failed attempt to reach an audio input device, the call will fail.

Potential Causes

Common Solutions

  • Microphone not available or plugged in

  • Microphone not allowed by browser or OS privacy settings

  • Sharpen Q phone not connected to Sharpen WebRTC infrastructure

  • Validate physical connection of headset or microphone

  • Validate/update audio driver for device handling microphone

  • Choose appropriate audio device for mic input from OS input chooser

  • Allow access to microphone through OS for specific apps

  • Allow access to microphone through browser for specific pages

  • Validate/set the appropriate microphone in browser

  • Validate ports necessary for WebRTC are open

  • Work with SharpenCare to confirm healthy operations of WebRTC and Voice Processor infrastructure

Applicable guides

One-way audio. Agent cannot hear remote side. Remote side can hear agent

One-way audio can be frustrating and difficult to solve because you only have controls of a few of the required components to make this work. When an agent cannot hear the remote side, in most cases it is either a speaker configuration issue, or a problem with the remote end. It’s recommended in these situations to make repeat attempts to see if the behavior is consistent.

Potential Causes

Common Solutions

  • Agent output device/speaker set incorrectly in OS

  • Agent output device/speaker faulty or disconnected

  • Remote side device fault

  • Remote side carrier service interruption

  • Sharpen voice infrastructure interruption

  • Validate output device is set appropriately in OS settings

  • Replace audio output device

  • Retry call and consult with remote end to work correct their device

  • Retry call and consult with remote end to resolve issue with their carrier

  • Work with SharpenCare to observe and troubleshoot the health of webRTC and Voice Processor infrastructure

Applicable guides

One-way audio. Agent can hear remote side. Remote side cannot hear agent

In most situations, this will be caused by a local microphone connection or configuration with the agent’s workstation. It’s always good practice to place controlled test calls to validate 2-way audio before the start of business if you’re concerned with one way audio.

Potential Causes

Common Solutions

  • Agent input/microphone not configured correctly in OS

  • Agent input/microphone defective

  • Remote side audio device not configured correctly

  • Remote side audio device defective

  • Sharpen voice infrastructure interruption

  • Validate input device/microphone is properly configured in OS

  • Replace input device/microphone

  • Retry call and consult with remote end to work correct their device

  • Work with SharpenCare to observe and troubleshoot the health of webRTC and Voice Processor infrastructure

Applicable guides

Unexpected dropped call

Dropped calls, as the list above suggests, have a variety of potential root causes. Most dropped calls are a result of poor mobile connections from the remote end. While mobile carrier networks continue to improve, we recommend following up with the remote end promptly to see if they may have been in a questionable signal zone.

If the source of the disconnect is not clearly identifiable, working with the SharpenCare team can help us get closer. Our logging can confirm whether the dropped call was initiated by the agent side, system side, or remote end. If you need to track down an important dropped call and need some assistance, please raise a request.

Potential Causes

Common Solutions

  • Remote side carrier service interruption

  • Remote side device fault

  • Agent ISP service interruption

  • Agent local network service interruption

  • Agent browser interruption

  • Agent workstation interruption

  • Agent audio device interruption

  • Sharpen voice infrastructure interruption

  • Re-engage with party for which dropped call occurred. Determine whether this was expected or unexpected on their end.

  • Inquire with agent’s ISP to determine whether there was a known outage at the time of the unexpected event.

  • Validate local network equipment uptime and performance statistics. Determine whether competing local network activity such as streaming/gaming/heavy downloading occurred at the same time.

  • Validate browser operation. Are web pages responsive or slow to load? Confirm the browser tab did not freeze or consume system resources.

  • Validate user workstation has available resources. CPU, Disk, or memory exhaustion which interrupt timely functions can cause our webRTC connection to drop. Adding memory or upgrading the workstation may be necessary.

  • Validate audio device (microphone/headset) did not experience a disconnect or fault. Sometimes, especially with usb connected devices, a brief disconnection can cause the OS and browser to loose knowledge of the device, and drop the call.

  • Work with SharpenCare to observe and troubleshoot the health of webRTC and Voice Processor infrastructure. We may ask to retrieve browser logs (if available) to more specifically identify the issue.

Applicable guides

Delayed audio

Delayed audio is inherently caused by latency at some point between the caller and called party. Most commonly this will be a result of network congestion or network latency concerns. For example, a user calling from the US to Australia will certainly experience latency due to the distance between the parties. However, if two users in the United States are dealing with delay problems, there are very likely network or hardware inefficiencies preventing the timely delivery of data to each party.

Potential Causes

Common Solutions

  • Carrier service latency

  • Agent ISP service latency

  • Agent local network latency

  • Agent browser degradation (memory exhaustion)

  • Agent workstation degradation (CPU/memory exhaustion)

  • Sharpen voice infrastructure degradation

  • Call the remote party back. Is the experience consistent, and does it happen when called from a non-Sharpen phone? If so, it can be concluded that the delay is on the remote end.

  • Open a request with the agent or organization ISP(Internet Service Provider). While ISPs can sometimes be slow to reveal information to confirm interruption, the best ammunition we have is timely reports. If something has gone beyond 24 hours from the impact, we’re not likely to get the information we need. Make sure to be specific with impact and ask very clearly whether any interruptions occurred.

  • Open a request with the local network team. Power exists in numbers. If this impacted many agents on the same network, there’s a higher likelihood the issue exists within the local network.

  • If suspecting workstation degradation, leverage the agent’s operating system resource monitor to validate sufficient memory, CPU, and disk exists. While there’s no specific rule here, if any of these resources is encroaching on 80% utilization, it would be best to increase availability.

  • Work with SharpenCare to observe and troubleshoot the health of webRTC and Voice Processor infrastructure. We may ask to retrieve browser logs (if available) to more specifically identify the issue.

Choppy audio

Choppy audio problems can have similar origins to delayed audio, but there’s one key difference. Choppy audio is the result of lost or non-processed packets, whereas delayed audio is simply a slower delivery of ordered packets. Typically choppy audio is going to be the result of performance constraints of some piece of equipment facilitating the audio stream. This could be local workstation resource exhaustion, network equipment, Voice Processor resource constraints… etc.

Potential Causes

Common Solutions

  • Carrier service degradation

  • Agent ISP service degradation

  • Agent local network degradation

  • Agent browser degradation (memory exhaustion)

  • Agent workstation degradation (CPU/memory exhaustion)

  • Sharpen voice infrastructure degradation

  • Much like delay, its worth calling the remote party back. Is the experience consistent, and does it happen when called from a non-Sharpen phone? If so, it can be concluded that the source of the choppiness is on the remote end. If not, something may be occurring locally, or within the Sharpen service.

  • Open a request with the agent or organization ISP(Internet Service Provider). Validate whether packet loss to your endpoint is being witnessed. While ISPs can sometimes be slow to reveal information to confirm interruption, the best ammunition we have is timely reports. If something has gone beyond 24 hours from the impact, we’re not likely to get the information we need. Make sure to be specific with impact and ask very clearly whether any interruptions occurred.

  • Open a request with the local network team. If this impacted many agents on the same network, there’s a higher likelihood the issue exists within the local network.

  • If suspecting workstation degradation, leverage the agent’s operating system resource monitor (Activity Monitor on MacOS, Task Manager on Windows) to validate sufficient memory, CPU, and disk exists. While there’s no specific rule here, if any of these resources is encroaching on 80% utilization, it would be best to increase availability. Your workstation’s inability to process in a timely manner could be preventing the processing of audio packets.

  • As always, if you’re unable to determine the source of the problem locally, there’s a chance Sharpen infrastructure may not be doing what we expect. Please open a SharpenCare request and we can investigate the health of our resources.

Static audio

Crackly static or jittery calls can have many of the same causes as echoes and delays. However, most commonly, due to it’s analog nature, static interference is going to be the result of a physical interruption to the audio device. While we’d love to be able to correct this problem, static concerns need to be focused on the audio hardware in use. We’re all surprised how often a slightly disconnected headset can cause this issue.

Potential Causes

Common Solutions

  • Electromagnetic Interference

  • Faulty power connection for audio device

  • Faulty device connection

  • Damaged cabling

  • It seems elementary, but if you’re getting static, start moving cables and reconnecting devices. Physical interference requires physical changes to address. Sometimes cables get old, connections get loose, and wires get dusty.

  • Try a backup device. Does the same issue happen even when you switch the headset out? Keep tackling the devices in a systematic order, ruling out devices as you go.

Echo

Echo is recognizable when you hear your own voice after you’ve spoken, or you hear the other side of the call twice. Frequently, echo is the result of having microphone gain too high, with a high volume speaker. This causes the signal to loop and re-present.

Potential Causes

Common Solutions

  • Acoustic Interference

  • Microphone/speaker gain/volume configurations

  • Poor internet connection

  • Faulty microphone/speaker

  • Validate you’re in an acoustically sound room. Rooms with reflective materials can send audio right back to your mic and cause echo.

  • Make sure your microphone isn’t too hot, and that your speaker volume isn’t too loud. If you get this combination too exagerated, you’ll experience echo and/or feedback. While there are no officially endorsed call tests, performing a web search for “echo test call” will yield results that allow you to validate whether your environment is causing echo.

  • Upgrade your internet connection. If your internet connection is lacking bandwidth you may be experiencing echo.

  • If no other options are working replace or try a backup device to see if the issue continues.

  • No labels