Description of the Issue
We are experiencing a highly frustrating and intermittent audio issue affecting our users during 3CX WebMeetings. The primary symptom is that a user will start their day hosting several consecutive, one-hour meetings. The first few meetings work perfectly with bidirectional audio. However, at a random point later in the day, the local user can no longer hear the remote client, resulting in one-way audio.The issue specifically seems to trigger when a user transitions from an ended/waiting meeting directly into a newly started meeting. It appears as though the audio communication channel or WebRTC session fails to re-initialize properly after multiple back-to-back sessions.
Environment & Architecture
- 3CX Version: Version 20.0 Update 9 (Build 995 Release - AI 1.4.48)
- Feature: 3CX WebMeeting / Video Conferencing (via the newly redesigned Web Client / PWA)
- Cloud Infrastructure: Utilizing the North American MCU Server
- Scope: It does not affect all employees. It occurs randomly across different team members.
Troubleshooting Already Attempted
- Client Diagnostics: We have attempted to identify a trend by tracking the remote clients' operating systems and web browsers (e.g., Chrome, Edge, Safari, Firefox). No specific pattern or trend has been found, as it happens regardless of the client's setup.
- Internal Environment: The issue seems isolated to the transition between consecutive sessions on the host's side, rather than a permanent network blockage, since early morning meetings work without fault. Given that we are running the newly overhauled Web Client framework in Update 9, we suspect an intermittent caching, token-refresh, or WebRTC port-handling bug between consecutive meetings.
Questions & Requested Assistance
- Known Issues: Has there been any recent telemetry or reported bugs regarding WebRTC session-handling failures on the North American MCU servers or specifically within the new Update 9 Web Client code when users run back-to-back meetings?
- Replication Steps: What is the recommended methodology to force-replicate this issue in a controlled environment?
- Diagnostics & Logging: What specific logs (e.g., browser console logs, WebRTC dumps, or server-side logs) should we capture from the host's machine at the exact moment the audio drops so that we can provide you with actionable data?
