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.