A step-by-step guide to diagnosing microphone, connection, and audio transmission issues during two-way voice conversations with an agent in Web Messenger.

This guide provides a shared set of checks for investigating browser-based Voice Assistant issues. Menu labels may vary by browser language and version. The examples use Chrome.

Key check: Working text chat does not mean the voice connection is working. Verify microphone access, both voice WebSocket connections, voice room participation, and audio transmission in both directions separately.

1. How a voice call works

1. The user opens Voice Assistant in Web Messenger and clicks Start Call.
   
2. The browser requests microphone permission when needed. The user selects the correct microphone and allows access.
   
3. The required voice connections are established and the user joins the voice room.
   
4. The user's speech is processed and the agent's response plays in the browser. Connections and audio transmission must remain active throughout the call.
   

Success criteria: In addition to seeing Connected, confirm that the agent understands the user's speech and the user can hear the agent's response.

2. Quick checks by symptom

3. Microphone and audio output permissions

3.1. Browser microphone permission

1. Open the actual web page hosting Messenger and click Start Call.
   
2. Select the intended device in the microphone permission prompt. Depending on the browser, options may include Allow while visiting the site or Allow this time. Choose an option that permits microphone use; blocking it prevents microphone access during the call.
   
3. If access was previously blocked, check Microphone in the site information/permissions menu next to the address bar. If necessary, open site settings, change the permission, and reload the page.
   
4. Check which site origin is requesting access. The public.jetlink.io page in the examples is a test page; the requesting origin may differ in your deployment.
   

3.2. Operating system and device checks

• Windows: In Settings → Privacy & security → Microphone, check microphone access and access for desktop apps such as the browser. Menu labels may vary by version.
  
• macOS: In System Settings → Privacy & Security → Microphone, check the permission for the browser.
  
• Confirm that the microphone selected in the browser is the device actually being used. The operating system's input level indicator should respond when you speak.
  
• Check the headset's physical mute button and the microphone status in the call interface. Bluetooth connections or docking changes may affect the selected device.
  
• If another application is making the device unavailable, close that application and try again. Restart the browser after changing permissions if needed.
  
• Also check the output device, system volume, and whether the browser tab is muted.
  

3.3. Page and integration checks

The production page must run in a secure context, normally over HTTPS. For iframe-based integrations, the parent page's Permissions-Policy and iframe permissions may restrict microphone access. Check the policy for the actual requesting origin. If a corporate browser policy blocks the microphone, review that policy.

4. Preparing to capture the issue

Open developer tools before reproducing the connection issue. Opening Network afterward may miss the initial connection requests.

1. In Chrome/Edge, open developer tools with F12 or Ctrl+Shift+I; on macOS, use Cmd+Option+I.
   
2. In Network, confirm recording is enabled, enable Preserve log, and select No throttling.
   
3. In Console, enable Preserve log. Clear text filters and display all log levels. If an iframe is involved, inspect its execution context as well.
   
4. Clear existing logs, reload the page, and start the call. Record the date, time, and time zone of the issue.
   
5. Say a short test sentence containing no personal information. Note whether the issue occurs during permission handling, room connection, or the conversation.
   

Review the first error together with subsequent events. For example, a connection error following a denied microphone permission may be a consequence of the original issue.

5. Inspecting WebSocket connections

5.1. Connections to check

These addresses identify server origins. Actual requests may include additional paths and session parameters. Inspect the actual request generated by Messenger. Opening the address in the browser address bar or making a manual unauthenticated WebSocket attempt does not prove that calls work.

5.2. Network → Socket / WS checks

1. In Network, select the Socket filter, or WS depending on your browser version.
   
2. Find both voice domains. If the domain column is not visible, check Headers → Request URL for each request.
   
3. Record each connection's status separately. For an HTTP/1.1 WebSocket handshake, 101 Switching Protocols indicates a successful protocol upgrade.
   
4. Open the request's Messages tab. Inspect sent and received message timestamps and activity during the call. Some versions call this tab Frames. Binary content may not appear as readable text.
   
5. If the call drops, inspect the same request for closure/error details and review Console logs from that moment. Record repeated opening and closing of new connections as well.
   

The results from the supplied Network screenshot are reproduced below. A table is used instead of the raw screenshot to avoid publishing session information in URL query parameters.

How should 101, Pending, and 0.0 kB be interpreted? A 101 status indicates that the connection opened; it does not by itself prove that the room is ready or audio is flowing in both directions. An open WebSocket may normally show Pending. A 0.0 kB value in the request list also does not, by itself, mean there is no traffic. Use Messages and media checks.

5.3. If the connection is missing from the list

First confirm that recording started before the call and that filters are not hiding the request. Then inspect the first Console error. A microphone error or an application startup error may have prevented the connection attempt. A missing request is not, by itself, evidence of a firewall block.

6. Joining the room and verifying two-way audio

6.1. Joining the room

Record whether the interface changes to Connected after Start Call. If it remains in a connecting state, review both WebSocket statuses, room-related Console logs, and any session/authentication errors together. Token expiry, session authorization, or a service error can produce symptoms similar to a network block; confirm the cause using server logs.

6.2. End-to-end audio test

1. Have the user say a short test sentence. Confirm that the correct microphone is picking up sound.
   
2. Check whether the agent responds meaningfully to that sentence. If available, use the transcript as supporting evidence.
   
3. Confirm that the response is audible through the headphones or speakers.
   
4. Exchange several conversational turns to check that transmission continues. Hearing only the opening audio is not sufficient.
   

6.3. If WebSockets connect but audio does not work

WebSocket establishment and end-to-end audio transmission must be verified separately. In sessions using WebRTC media transport, not every audio packet is expected to appear in the WebSocket Messages tab. Supplement connection checks with a real conversation test and, when needed, media statistics.

If the session uses WebRTC, open chrome://webrtc-internals in Chrome before the test to inspect ICE/connection status and audio statistics. Increasing bytesSent, bytesReceived, or packet counters for the relevant audio stream during the call provide supporting evidence. Available fields vary by version and stream. Increasing counters alone do not prove that intelligible audio is audible; evaluate them alongside the conversation test.

If ICE fails or media packets do not flow, check media connectivity as well. This document does not list environment-specific additional media/TURN domains and ports. If the checks do not resolve the issue, confirm the environment's connection requirements during second-level support investigation.

7. Interpreting Console errors

The messages below are examples of possible errors; the supplied screenshots do not show these errors occurring. Record the complete actual message, its time, and the operation it relates to.

The Console Issues counter is not a count of voice failures. Check each entry's timestamp and relationship to the voice call. Do not report unrelated page warnings as the root cause.

8. Corporate network, VPN, and security checks

8.1. Network access and security checks

• Both voice domains must resolve through DNS and allow outbound connections over TCP 443, the default WSS port.
  
• The firewall/proxy must support the WebSocket handshake and long-lived, bidirectional connections. Where HTTP/1.1 is used, verify that Upgrade traffic is not blocked.
  
• Correlate URL filtering, TLS inspection, proxy authentication, and endpoint security logs with the time of the issue.
  
• If the connection drops after a while, inspect proxy/VPN session and idle timeout policies.
  
• Check for organizational restrictions on browser microphone policies, operating system permissions, and the page's CSP/iframe permissions.
  
• If WebSocket access works but media does not, confirm environment-specific WebRTC/TURN access during second-level investigation. Do not assume that TCP 443 access alone is sufficient for the entire voice system.
  

8.2. Controlled comparison tests

Run tests using devices and networks permitted by your organization. Use approved test conditions rather than disabling VPN or security products without authorization. Use the same page, a comparable session, and the same conversation steps for each test.

A successful DNS query or ping does not prove that a WebSocket can connect. A successful WebSocket connection does not prove that the microphone or media transmission works.

9. Verification after a fix

Verify the fix on the original corporate device and under the network conditions where the issue occurred. The following is a suggested acceptance test, not a product duration or performance guarantee.

• Microphone permission can be granted and the selected microphone detects sound.
  
• Both voice WebSockets connect successfully and do not disconnect unexpectedly.
  
• The user joins the voice room and the interface shows Connected.
  
• Across several conversational turns, the user's speech is understood and the agent's replies are audible.
  
• The connection and audio transmission continue during an approximately two-minute test. If the issue previously occurred later, extend the test to cover the observed disconnection interval.
  
• The call can be ended and restarted. The relevant errors do not recur in the new call.
  

Resolution record: Add the change made, test conditions, and two-way audio test results to the support record.

10. If the issue persists

If the checks and tests in this guide do not resolve the issue, escalate it to Jetlink IT for second-level support.

To help continue the investigation, share the step at which the issue occurs, the results of the checks, and the error time and time zone. Include relevant Console errors, the results for both voice WebSocket connections, and screenshots of the issue where available. No specific reporting format is required.

Remove tokens, access_token values, cookies, Authorization headers, and personal information from shared records. Send necessary session references only through an authorized support channel. Do not share API keys, JWT signing secrets, or session tokens.

If a HAR file or WebRTC diagnostic output is requested for further investigation, review its contents before sharing. HAR files may not include all WebSocket messages or media statistics; relevant screenshots and Console logs may also be needed.

11. Frequently asked questions

Why does text chat work while voice does not?

Voice uses separate connections and microphone access. A working chat connection does not prove that both voice WebSockets, room participation, or audio transmission work.

Both WebSockets returned 101. Are we done?

No. Test room participation and a two-way conversation. If audio issues persist, inspect input/output devices, playback permissions, and the media connection in use.

Is Pending an error?

Not by itself. A WebSocket can remain open throughout the call. Evaluate its status alongside Messages, closure events, and the audio test.

Does an empty Console mean there is no issue?

No. Recording may have started too late or logs may be filtered. Show all levels and reproduce the issue. Also check Network and perform an end-to-end audio test.

What does it mean if voice works outside the VPN?

It suggests that the network path may be involved, but does not identify the exact cause. Confirm using proxy, firewall, and VPN logs from the same time window.