My rtms client connects successfully but then immediately disconnects with stop reason 18

Realtime Media Streams
1

I have an rtms zoom app to console log transcripts, which works fine locally via ngrok.

Once I deploy it to AWS ECS, I’ve got an issue where the rtms client connects succesfully, and then immediately gets a webhook event for meeting.rtms_stopped, with stop reason 18.

According to the docs this is due to an authentication error, but I can’t think why authentication would be different unless something is being blocked by the different hosting environment and its networking.

My logs are as follows:

Processing webhook payload: {
  event: 'meeting.rtms_started',
  payload: {
    meeting_uuid: '5JDigjq5RNeaL9AurmF2/w==',
    operator_id: 'vwNuDndDRPqJJU9XJoE5FQ',
    rtms_stream_id: 'f6ccaa9d7c0f432397a755bd1365d2c6',
    server_urls: 'wss://zoomams159-124-17-24zssgw.ams.zoom.us:443'
  },
  event_ts: 1753971045343
}
rtms     | 2025-07-31T14:10:45.561Z | DEBUG | SDK already initialized
global   | 2025-07-31T14:10:45.561Z | INFO  | Joining meeting: 5JDigjq5RNeaL9AurmF2/w==
rtms     | 2025-07-31T14:10:45.561Z | DEBUG | Generating signature for client: kt5g8xndTK9gGZm7S8FFw, uuid: 5JDigjq5RNeaL9AurmF2/w==, streamId: f6ccaa9d7c0f432397a755bd1365d2c6
global   | 2025-07-31T14:10:45.562Z | INFO  | Successfully joined meeting: 5JDigjq5RNeaL9AurmF2/w==
global   | 2025-07-31T14:10:45.562Z | DEBUG | Starting global polling with interval: 0ms
Processing webhook payload: {
  event: 'meeting.rtms_stopped',
  payload: {
    meeting_uuid: '5JDigjq5RNeaL9AurmF2/w==',
    rtms_stream_id: 'f6ccaa9d7c0f432397a755bd1365d2c6',
    stop_reason: 18
  },
  event_ts: 1753971045977
}
global   | 2025-07-31T14:10:46.178Z | INFO  | Leaving meeting
global   | 2025-07-31T14:10:46.178Z | DEBUG | Stopping global polling
global   | 2025-07-31T14:10:46.179Z | INFO  | Successfully released resources
2

Hey @bbodien (welcome to the forum :waving_hand: ), we’ll look into this and see if we can reproduce with the SDK. Unless this is a certificate issue, I’d expect this is behavior the SDK should handle for you.

3

Thanks, Michael! The only thing I was clutching for is that there’s something on the Zoom side which kicks rtms out if the app is in local development mode, and the event notification endpoint url is something other than localhost? We were going to try and get it into beta test mode next to see.

4

Hey @bbodien , @MaxM @chunsiong.zoom and I have done some testing and have seen this behavior happen if the client ID or secret are incorrect. Can you confirm your credentials are pulling into ECS? The SDK checks if credentials are blank, but not incorrect.

If these are correct, can you share more about your ECS environment to verify the issue isn’t related to the certificate or network? Is there any type of load balancing or routing happening? We’d like to help replicate and get this settled.

5

The event notification URL should only affect the webhook delivery and would not affect the RTMS connection.

6

Okay, it looks like it was the secret being malformed. It turns out it’s staggeringly easy to accidentally define a secret in AWS Secrets Manager as a key value pair rather than just a plain text string, and so my secret was being delivered to the app as a serialized json object.

I’d assumed that the initial connection to the room would have failed if the credentials were incorrect, hence ruling out further investigation on my end into this!

Sorry for the wild goose chase!