Meeting SDK Type and Version
- Zoom Meeting SDK for Linux, headless C++ integration
- Primary reproduction: 6.3.5 (6495)
- Similar behavior was also observed with 7.1.0 (4100)
- OS: Ubuntu 22.04-based NVIDIA TensorRT container
- Runtime: Kubernetes Pod on a North American server
- Architecture: x86_64
- Event loop: GLib events pumped every 10 ms
- No browser is involved
Description
We are implementing a headless Linux Meeting SDK bot that starts a meeting as the host using a ZAK.
SDK authentication succeeds, and IMeetingService::Start() returns SDKERR_SUCCESS. The participant then becomes visible in the Zoom meeting as the host,
but the local Linux SDK remains in MEETING_STATUS_CONNECTING indefinitely and never reports MEETING_STATUS_INMEETING.
In our complete application, even while the SDK reports Connecting:
- The bot is visible in the meeting as the host.
- External video can be published and is visible to other participants.
- Participant join and leave callbacks are received.
- Bidirectional Zoom media traffic is present.
However, functionality that appears to require the complete in-meeting state remains unavailable:
- The bot does not join VoIP successfully.
- External audio does not work.
- Raw recording cannot be started.
- Meeting chat messages are not received.
We created a standalone minimal C++ reproduction that performs only:
- InitSDK()
- SDKAuth()
- CreateMeetingService()
- CreateSettingService()
- EnableAutoJoinAudio(true)
- Register meeting and reminder event listeners
- Call IMeetingService::Start() using a newly generated ZAK
- Pump GLib events and poll GetMeetingStatus() for 120 seconds
The minimal reproduction does not initialize raw recording, external audio/video sources, chat, participant subscriptions, CUDA, renderer IPC, or any
application-specific media pipeline.
Error?
There is no explicit SDK error. Authentication and Start() both return success.
The relevant output is:
[MINIMAL] InitSDK=0 version=6.3.5 (6495)
[MINIMAL] CreateAuthService=0
[MINIMAL] SDKAuth=0
[MINIMAL] auth callback result=0
[MINIMAL] CreateMeetingService=0
[MINIMAL] Meeting SetEvent=0
[MINIMAL] CreateSettingService=0
[MINIMAL] EnableAutoJoinAudio=0 enabled=1
[MINIMAL] Reminder SetEvent=0
[MINIMAL] Start=0 direct_status=1
[MINIMAL] meeting callback status=1 result=0
[MINIMAL] meeting parameter notification
For the next 120 seconds:
[MINIMAL] elapsed=120s callback_status=1 direct_status=1
[MINIMAL] final_status=1
1 corresponds to MEETING_STATUS_CONNECTING.
The SDK never reports MEETING_STATUS_FAILED, and the callback result remains 0.
Troubleshooting Routes
We have tested the following:
- Reduced the application to a standalone minimal C++ reproduction.
- Compared the SDK lifecycle and media initialization timing with Zoom’s official Linux raw-recording sample.
- Removed raw recording, external media, chat, participant subscription, renderer, IPC, CUDA, and inference logic from the reproduction.
- Tested Meeting SDK 6.3.5 (6495).
- Observed similar behavior with Meeting SDK 7.1.0 (4100).
- Generated the OAuth access token, ZAK, and a brand-new instant meeting directly on the North American server immediately before calling Start().
- Confirmed the ZAK belongs to the meeting owner.
- Tested with a fresh Kubernetes Pod.
- Tested with only one Meeting SDK process running.
- Removed the existing .zoomsdk state directory before testing.
- Confirmed /etc/machine-id is valid and matches /var/lib/dbus/machine-id.
- Confirmed SDK and Qt shared libraries are loaded from the expected 6.3.5 SDK directory.
- Confirmed SDK callbacks are pumped through the GLib event loop.
- Confirmed TCP 443 connectivity and TLS certificate validation.
- Captured the meeting network traffic with tcpdump.
The packet capture confirms bidirectional connectivity for:
TCP 443
UDP 3478
UDP 3479
UDP 8801
The assigned Zoom media server responds to UDP 8801 in approximately 1–2 ms. During the 120-second reproduction, thousands of approximately 1036-byte
UDP packets are exchanged in both directions.
Therefore, this does not appear to be a blocked UDP port, missing return route, NAT timeout, or basic connectivity issue.
The same minimal binary and Meeting SDK version can reach MEETING_STATUS_INMEETING in a local environment, but consistently remains in
MEETING_STATUS_CONNECTING in the North American Kubernetes environment.
Encrypted Meeting SDK logs and packet captures are available and can be shared privately with Zoom support.
How To Reproduce
-
Use Meeting SDK credentials to generate a Meeting SDK JWT.
-
Call InitSDK() with the Zoom web domain and SDK logging enabled.
-
Create the authentication service and call SDKAuth().
-
Wait for onAuthenticationReturn(AUTHRET_SUCCESS).
-
Using user-level Zoom OAuth:
- Exchange a refresh token for an access token.
- Call GET /v2/users/me/zak.
- Create a new instant meeting using POST /v2/users/me/meetings.
-
Create IMeetingService and register IMeetingServiceEvent.
-
Create ISettingService and call EnableAutoJoinAudio(true).
-
Configure StartParam4WithoutLogin with:
- The newly created meeting number
- The newly generated ZAK
- ZoomUserType_APIUSER
- Audio enabled
- Video disabled
-
Call IMeetingService::Start().
-
Continuously pump GLib events.
-
Poll IMeetingService::GetMeetingStatus() for 120 seconds.
Actual result:
Start() returns SDKERR_SUCCESS.
The participant appears in the meeting as host.
Network and media transport are bidirectional.
The SDK remains in MEETING_STATUS_CONNECTING.
Expected result:
onMeetingStatusChanged reports MEETING_STATUS_INMEETING.
GetMeetingStatus returns MEETING_STATUS_INMEETING.
Could you please inspect the encrypted SDK logs and advise why the Linux Meeting SDK does not transition from MEETING_STATUS_CONNECTING to
MEETING_STATUS_INMEETING, even though the participant and media transport appear to be established?