RTMS Python SDK 1.1.0 — Initial participant IDs, reconnection, shutdown, and negotiated audio format

Realtime Media Streams
1

We are deciding whether to implement an audio-only Zoom Meetings PoC with rtms==1.1.0 on CPython 3.12.15 and macOS ARM64. We plan to use one client for a meeting with two participants, including the host. The host’s user-managed General App uses auto-start, the meeting:read:meeting_audio scope, and the meeting.rtms_started and meeting.rtms_stopped webhooks.

The receiver requests RAW_AUDIO, L16, SR_16K, MONO, AUDIO_MULTI_STREAMS, duration=20, and frame_size=320. It must stop on interruption, pause, configuration rejection, or format mismatch. It must never reconnect or resume automatically.

S1. How can we get the IDs of participants who are already in the meeting?

  1. Which public API or callback reliably delivers the IDs of both participants who are already in the meeting when RTMS connects, including the host and anyone who is muted? What registration and subscription sequence ensures that the receiver gets those initial IDs? In the 1.1.0 binding, subscriptions registered before allocation appear to be queued without being applied during allocation. Python binding
  2. Within the same meeting and stream, are Participant.id from on_user_update and user_id from on_participant_event guaranteed to match the corresponding audio metadata.userId? Is there a signal that the initial list is complete or a documented delivery deadline? Can audio arrive before the participant notifications?

S2. Can the native SDK reconnect or resume on its own?

  1. If the application calls join() only once, can the bundled native SDK reconnect after a signaling or media disconnect or server failover, or resume delivery after a pause? Can that happen before the application receives an interruption or pause notification?
  2. If any of these can occur, which public API or setting in 1.1.0 prevents them, and when must it be applied?

S3. Which SDK signals establish connection, interruption, and shutdown?

  1. Which on_join_confirm(reason) value establishes that the audio connection is ready? Which SDK callbacks and reason or op values distinguish a pause, signaling interruption, media interruption, normal termination, and stream revocation? In particular, does signaling interruption require a separate meeting.rtms_interrupted subscription, and can the SDK itself report revocation before the meeting.rtms_stopped webhook with stop_reason=8 arrives? Zoom webhook reference
  2. Is it supported to request shutdown in a callback and call leave() on the owning OS thread after poll() returns? Can the same sequence be used before join confirmation and after the stream has ended? What public result confirms local cleanup or reports its failure? The 1.1.0 binding disables callbacks before releasing the native client. Python release path

S4. How can we verify the negotiated audio format and stop on rejection?

  1. Which public Python API in 1.1.0 exposes the server-confirmed media_params or equivalent values for content type, codec, sample rate, channels, data option, and send interval? Media handshake response
  2. Which public result or callback lets the application reliably detect a configuration rejection or format mismatch before accepting audio? The 1.1.0 wrapper can log a warning on a native configuration error and still call the native join. Configuration path before join

Please answer for rtms==1.1.0 and link to the relevant API definitions where available. If a requirement has no supported public API in this version, please say so. SDK source for v1.1.0 · PyPI release