Broken RTMS Websocket

Realtime Media Streams
1

My app users (beta) are not able to connect to RTMS.

Any user that does not have RTMS explicitly enabled in the app gets the in-meeting message that the app could not connect to meeting content. I can see in logs that I am no longer receiving RTMS webhooks for users in this configuration. (Accounts that have explicit RTMS approval work fine.) This was not the case 1-2 weeks ago.

Online documentation insists that without explicit Zoom approval for an account to use RTMS, app users do not have access to it. I have not found this to be true: calling startRTMS used to initiate a stream and send the webhook, regardless of account provisioning.

However, now, the startRTMS method returns success but no rtms_started webhook is reaching my endpoint.

@elisa.zoom

2 Likes
2

I just noticed - when I hit the button that runs startRTMS, I see an alert that says “Your app failed to access meeting content.”

3

Hi @John34 ,

Happy to investigate this. I am going to DM you right now, please provide me with the following:

  1. App ID / Client ID
  2. Meeting IDs
3 Likes
4

@ojus.zoom Please respond when you can. I need to resolve this ASAP.

The Problem

I spent a lot of time over the weekend trying to figure out what’s going on.

Users cannot start an RTMS stream if they (a) aren’t on my account, (b) haven’t explicitly requested RTMS from Zoom, or (c) aren’t in a meeting with someone who has RTMS. My app is in beta, so it is available for use by users outside of my development account.

For these beta users, I had a button in my UI for them to Start RTMS. This called zoomSdk.startRTMS() and started an RTMS stream for them. This was working for about two weeks, including for users who didn’t meet the criteria above - i.e., weren’t on my account, hadn’t explicitly requested RTMS from Zoom, and weren’t in a meeting with someone who had RTMS.

As of Friday 11/14, this is no longer the case. Now, when a user presses the Start RTMS button, they see an alert that says, “Your app failed to access meeting content,” and Zoom does not send a meeting.rtms_started webhook to my app’s backend.

However, all of this still works for users who are on my Zoom account, or who have requested RTMS from Zoom in the past.

I tested this a few times today, and sent you some more meeting_uuids for meetings where the issue occurred.

Possible Solutions

  • Permissions: All over the internet, I see hints that app users must be on the developer account, or have requested RTMS from Zoom, in order to start an RTMS stream. However, I know this not to be true, since I had users who did not meet those criteria successfully starting RTMS streams.

  • Additionally, this would be an unreasonable requirement, since the process of requesting RTMS from Zoom takes multiple weeks, and would be a huge disincentive to installing these apps at all.

  • Scopes and Webhooks: I have reviewed my scopes, APIs, and webhooks closely. Although I’d like to review them with a Zoom developer advocate to be safe, I don’t see any red flags here.

  • startRTMS: When a user activates the Start RTMS button, my logs show a “Success” message. It appears the call is being made successfully. This is further evidenced by the “Your app failed to access meeting content” message in the Zoom client. This tells me that somewhere in the Zoom service, it is deciding not to send the RTMS webhook in response to startRTMS

In summary, it appears that before 11/14-ish, any of my app users could call startRTMS and trigger a meeting.rtms_started webhook – but after 11/14-ish most of them lost that ability.

Please let me know what I should try. I really need to get this fixed ASAP, as it is blocking my beta testers.

Thanks.

1 Like
5

Hey @John34, thanks for the depth here and apologies this was difficult to work through. Can we meet to discuss details on your app? I’ll DM you with more details.

1 Like
6

Sounds good, please DM me. Would like to find some time soon to walk through it.

1 Like
7

I have filed the form but exactly at the 5th minute the meeting is getting cut off but before it worked thoroughout.

Is this deliberate for internal users or how?

@michael.zoom ?

1 Like
8

I’ve actually experienced something similar, but we are not seeing this widespread from customers. Can you share your meeting UUIDs with me (for the meetings you’ve experienced this with) so I can look into this more? Thank you! @gauthambh

1 Like
9

@JenBrissman It looks like I’ve determined a fix, if not a root cause or justification.

If a Basic user has never added a credit card to their account, then they cannot - as of a week ago - start an RTMS stream.

However, if they add a credit card to their account, they can start an RTMS stream. This is true even if they subsequently remove the credit card. Once a credit card has been added, the “Share realtime meeting content with apps” setting appears in their account (defaults to TRUE).

@michael.zoom suggested this to me when we met yesterday. While it is not a fix - it’s an unnecessary extra step - it does give me a path forward. I’ve been advising my Basic account beta testers to add a credit card (and remove it if they wish) before they try to test.

1 Like
10

You can check out this meeting uuid which was generated in my account: 7H11HOe6RyW1Yw719w431w==

What ever I try, my RTMS app cuts off websocket connection exactly at 5 minutes and we need a solution for this as we have pro accounts from zoom.

11

@gauthambh are you using some sample code or are you connecting to the websocket directly?

For webhook, do ensure you immediately response status 200, if not there will bw another webhook which will fire 5 mins later. This duplicate webhook might cause the initial connection to drop, since there can only be 1 connection at any given time for that streamID.

2 Likes
12

Can I DM you with the code sample?

@chunsiong.zoom - It was working 1 month ago and calls are suddenly dropping for the past 2 weeks with the same exact code.

I used the code example from the zoom rtms docs.

1 Like
13

This issue was caused by a race condition where response 200 is not send immediately back to Zoom’s webhook service.

In this scenario, the webhook will attempt to retry 5 mins later. The logic attempts to connect to the same RTMS service 5 mins later, causing the original connection to drop, as there can only be 1 connection at a single point in time.

Solution: Send response 200 immediately after receiving webhook
Comprehensive solution: Keep a state of connected websockets, and prevent reconnection if the connection is alreadyactive.