Expectations around RTMS app users being given host role mid-meeting

Realtime Media Streams
1

I’ve noticed the following behavior:

  1. Zoom User with RTMS app joins a meeting that they host. RTMS session successfully starts (expected).

  2. Participant joins.

  3. User gives Participant the host role. RTMS session ends (expected).

  4. User leaves meeting.

  5. User re-joins meeting.

  6. User takes over host role. **RTMS session does not attempt to start (expected?).**

    Is 6. intended? Is that what Zoom RTMS devs expect? If so, why is that the case?

Thanks.

2

Hey @davej ,
Thanks for reporting this. After speaking internally, this seems to be the expected behavior. You would need to manually start RTMS in this case.

3

Thanks @ojus.zoom.

We’re currently relying on the meeting.rtms_started webhook event by way of auto-starting RTMS apps for certain users.

What do you mean when you say “manually start RTMS”, do you mean using the Update participant Real-Time Media Streams (RTMS) app status API? If so, can you confirm what kind of oauth grant type we’d need for an access token for that endpoint? (I have a feeling account_credentials would not suffice here, but wanted to double check on this.)

We’d love to do this automatically so that our users aren’t required to, e.g., hit a button via “surface” functionality. What would be a good webhook to listen to to determine when an RTMS-enabled user gains host capabilities in a meeting?

4

I’ve noticed similar behavior in RTMS host-transfer tests. It seems the RTMS session fully ends after the host role changes and doesn’t automatically restart when the original user becomes host again.

Would be helpful if the Zoom team could confirm whether this is expected behavior or if there’s a recommended way to restart the RTMS session.

5

Any updates on this issue?

I’m facing a similar use case where the meeting host transfers ownership to another participant who has the Zoom RTMS app installed. However, I’m unable to restart RTMS because Zoom doesn’t send any event that would allow me to invoke the Start RTMS API using the new host’s credentials/access token.

I’ve subscribed to the participant role changed event, but the event payload contains the same value for both the old and new roles, making it difficult to determine when the participant has actually become the host and when to trigger the Start RTMS API.

What is Zoom’s recommended approach for handling this workflow? Is there an event or best practice that applications should rely on to detect a host transfer and restart RTMS for the new host?

@chunsiong.zoom Could you please help here ? Thanks.