Persistent RSV1 error ; LLM websocket runtime error

Support Help
1

The conversatoin initiates successfully and works up until around the 1:30 mark. At which point, the conversation fails by cutting out. The dropped websocket call always shows the same error on analytics…From my understanding it is a known bug… RSV1 error indicates a websocket compression issue… apparently it triggers when the client side server recieves compressed frames it cant handle. I tried disabling websocket compression accross the entire backend server as it was the recommended fix, i made sure the corrrect ws package version was being used, server config was verified , all messages as json stringigied text… I do not know what else to do short of utilizing a different backend server provider which i do not really want to do. I am using Gpt4o with a firebase backend… I do not want to migrate to a new tts provider (retell is ridiculously good for the first minute and 30 seconds) … with my workflow, it seems Websocket is the fastest and easiest way to get a low latency legitimate conversation feel. any input or recommendations would be greatly appreciated .

2

Hey @nurbkny

Can you share the relevant Call Ids and your Agent Id?

3

hey, yes i would appreciate that. Every session functions flawlessly but when it makes it to about the 1:30 mark the websocket call abruptly cuts out. If the agent is speaking at that time, the speech will cease abruptly midsentence and the call effectively is terminated. All functions prior to this event are as intended and actually of extremely high quality. There are only 2 call id’s listed, but every call follows the same order of events. The analytics section summarizes the session status as error and explains it as error llm websocket runtime.

custom url: wss://retellllmwebsocket-5jjpbmkfra-uc.a.run.app
agent id: agent_755f7a0956137a4d71f25aa8a6

call_43d9efd8725bfac0e3ac719038e

call_ba29dd49183c52805cae051c738

2026-05-18 11:52:31.236 call_e09697ccca67a30e2bac75f1735 error: Call closed in error: RangeError: Invalid WebSocket frame: RSV1 must be clear
at Receiver.getInfo (/usr/src/app/node_modules/ws/lib/receiver.js:209:26)
at Receiver.startLoop (/usr/src/app/node_modules/ws/lib/receiver.js:155:16)
at Receiver._write (/usr/src/app/node_modules/ws/lib/receiver.js:94:10)
at writeOrBuffer (node:internal/streams/writable:570:12)
at _write (node:internal/streams/writable:499:10)
at Writable.write (node:internal/streams/writable:508:10)
at TLSSocket.socketOnData (/usr/src/app/node_modules/ws/lib/websocket.js:1360:35)
at TLSSocket.emit (node:events:509:28)
at addChunk (node:internal/streams/readable:563:12)
at readableAddChunkPushByteMode (node:internal/streams/readable:514:3) I tried all the recommended fixes as per retell publications. From my understanding, this may be an infrastructure issue. Right now i am using firebase for my backend … is it possible that the issue may respond to swithing backend server providers ? Any information would be greatly appreciated.

Thank you.

4

@nurbkny I’ve escalated this issue to our team for further investigation.

We’ll keep you updated as soon as we have more information.

Best regards

5

Hello @nurbkny Try:

```js
const wss = new WebSocket.Server({
noServer: true,
perMessageDeflate: false, // must be on the instance that handles our upgrade
});

How to verify in under a minute:

  1. Make a test call
  2. In your Cloud Run logs, inspect the response headers your server sends back on the WebSocket upgrade
  3. If you see Sec-WebSocket-Extensions: permessage-deflate in the 101 response, the extension is still being negotiated — perMessageDeflate: false is not on the right instance. Once that header is gone from the handshake response, the RSV1 crash will stop.

Thank You