Hi, I’m building a local integration that consumes in-meeting chat via RTMS (media_type 16). The whole pipeline connects successfully, but no chat data frames (msg_type 18) are ever delivered, regardless of who sends the message (host, co-host from another device, or participant).
Setup:
Pro account with Developer Pack active (pay-as-you-go)
General App (user-managed) with scope meeting:read:meeting_chat, RTMS events subscribed, app installed/authorized
RTMS started via PATCH /v2/live_meetings/{meetingId}/rtms_app/status with {"action":"start","settings":{"client_id":"<general app id>"}} → HTTP 204 ✓
meeting.rtms_started received via WebSocket event subscription ✓
Signaling handshake (msg_type 1, media_type 16) → status_code 0, media server URL returned under media_server.server_urls.chat ✓
STREAM_STATE_UPDATE state 1 (ACTIVE), SESSION_STATE_UPDATE state 2 (STARTED) ✓
In-meeting panel “Apps accessing meeting content” shows the app with “Access in progress — Access: Chat” ✓
KEEP_ALIVE handled on both sockets ✓
Problem: after this, the media socket stays silent forever: no msg_type 18, no msg_type 27, nothing — while chat messages are being sent in the meeting (tested host-only, host+phone participant, co-host). Meeting runs 5+ minutes.
Also tried subscribing the webhook/WS event “In-meeting chat message received” on a Server-to-Server app subscription: the event never fires either (other meeting events like meeting.started/ended arrive fine on the same connection).
Questions:
Is there an account-level setting (e.g., advanced chat encryption, continuous meeting chat / Team Chat-based meeting chat) that blocks RTMS chat delivery?
Does RTMS chat require any additional enablement beyond the Developer Pack?
Is meeting.chat_message_received deliverable over WebSocket subscriptions, and does it require extra scopes?
I have a headless Windows Meeting SDK bot (custom UI, ENABLE_CUSTOMIZED_UI_FLAG) that joins my own meetings to manage spotlight / participants. It was working until about June 13, 2026. Since around June 14–15 it authenticates fine but never enters the meeting — it stays in MEETING_STATUS_CONNECTING indefinitely. No code changed on my side (same .exe).
Setup
Windows Meeting SDK 7.0.5.39292 (latest Windows build)
C++ bot; InitSDK with ENABLE_CUSTOMIZED_UI_FLAG, enableLogByDefault = true, strWebDomain = "https://zoom.us"
App: General App with Meeting SDK enabled, Development credentials, on my own Pro account
Joining my own Personal Meeting Room (meeting on the same account as the app)
Anonymous join: SDK_UT_WITHOUT_LOGIN + JoinParam4WithoutLogin (meetingNumber, userName, psw, isVideoOff=true, isAudioOff=true, no userZAK, no onBehalfToken)
JWT signed with SDK Client ID/Secret, role=0, iat/exp/tokenExp per spec
…then nothing. Never reaches MEETING_STATUS_INMEETING (3), never MEETING_STATUS_FAILED (6), no iResult. Stays at CONNECTING for 2+ minutes and indefinitely. The bot never appears in the participant list.
Meeting security
Passcode-protected (passcode 0000). Tried both the plain passcode and the pwd= token from the join URL → same CONNECTING hang, never a password error / FAILED.
Waiting Room: OFF
“Only authenticated users can join”: OFF
Already ruled out
Firewall/AV: Norton Smart Firewall + Intrusion Prevention disabled → no change; nothing in Norton’s blocked-connections log.
Network: wired Ethernet, no VPN, no system proxy. The normal Zoom desktop client (6.7.8) connects fine to the same meeting on the same PC.
A clean PC reboot did not help.
One clue: on June 13 the SDK wrote plaintext logs (jump_maestro.exe_N.log in %APPDATA%\ZoomSDK\logs). Since June 14–15 it only writes encrypted logs (zoom_memlog_*.log.zenc). Looks like the SDK runtime updated itself in between.
Questions
What can cause a Meeting SDK join to stay at MEETING_STATUS_CONNECTINGforever, with no timeout and no MEETING_STATUS_FAILED?
Was there a recent (June 2026) change affecting same-account anonymous joins on the Windows SDK, or a new join-flow callback the app must implement that, if unhandled, leaves the join stuck at CONNECTING?
How can I get plaintext SDK logs again (or submit the encrypted .zenc logs) so the exact connection failure can be diagnosed?
For an anonymous join to the app owner’s own meeting, is it now required to enable “Request Anonymous Join Exception” and/or the “programmatic join use case” toggle?
Account ID and encrypted SDK logs available via DM. Thanks!