Problems with production client id/secret for general app

Realtime Media Streams
1

Hello.

I’m having trouble getting streaming data out of the beta client for RTMS.

I have Zoom general app with all of the permissions and scopes required by the RTMS docs.

When using the client id/secret for “development,” I successfully establish connections with the handshake and media servers. However, I receive no streaming data. (Interesting note: the app’s listing “Apps that can access content in this meeting” modal eventually tells that the connection failed, even though the connections persist in the application I’m building.) This is consistent with what @noah.duncan discovered here, so I attempted using the app’s “production” client id/secret.

However, when I use my Zoom app’s “production” client id/secret, the handshake connection is closed by Zoom shortly after performing the handshake request. i.e., the client id/secret used to generate the handshake request signature do not seem to work.

Would appreciate some guidance here. I imagine that I haven’t done something required for production setup.

Notes for Zoom folks:

  • this Zoom application is a test application under a test account for my organization; it is not under the account I’m currently posting under. This test account has been given RTMS abilities by Zoom.
  • my organization will not be exposing our Zoom General application(s) publicly; the intention is to make the app available only for certain Group(s) users that my organization creates/controls.
2

@davej is this issue still happening?

3

Hey @davej,

Are you able to log the response that you get after you make your handshake request?

The response should look something like this when you inspect the message after parsing the response using JSON.stringify() (or the equivalent for whatever language you are writing in):

{
  media_server: {
    server_urls: {
      all: "wss://zoomsjc-[INSERT_AN_ID_HERE]-zssgw.sjc.zoom.us:443",
      audio: 'wss://zoomsjc[INSERT_THE_SAME_ID_HERE]zssgw.sjc.zoom.us:443',
      chat: 'wss://zoomsjc[INSERT_THE_SAME_ID_HERE]zssgw.sjc.zoom.us:443',
      deskshare: 'wss://zoomsjc[INSERT_THE_SAME_ID_HERE]zssgw.sjc.zoom.us:443',
      transcript: 'wss://zoomsjc[INSERT_THE_SAME_ID_HERE]zssgw.sjc.zoom.us:443',
      video: 'wss://zoomsjc[INSERT_THE_SAME_ID_HERE]zssgw.sjc.zoom.us:443'
    }
  },
  msg_type: 2,
  protocol_version: 1,
  sequence: 0,
  status_code: 0
}

If it doesn’t look similar, then I’d make sure that your handshake request looks like this (from the event reference docs):

{
  "msg_type": 1,
  "protocol_version": 1,
  "sequence": 0,
  "meeting_uuid": "xxxxxxxxxx",
  "rtms_stream_id": "xxxxxxxxxx",
  "signature": "xxxxxxxxxx"
}

If that does look similar to what you are seeing, then the next place I’d look is at how you handle the KEEP_ALIVE messages. If you miss responding to several of those in a row, then your connection will close.

While we’ll have a more in depth tutorial out later, this primer that we put together on what is RTMS might help.

Alternatively, if you want to use RTMS and your organization already has access, you can integrate quickly by using Recall.ai’s unified API for conversation data. We capture meeting data via our meeting bots, using the Desktop Recording SDK, and RTMS.

4

I’m going to close this topic but if you’re still running into issues please open a new topic and link to this so that we can assist further.