AudioHook WebSocket disconnects - intermittent, East Coast latency?

Hey all,

Seeing intermittent disconnects on the AudioHook WebSocket stream-seems to happen roughly every 15-20 minutes, right around the time my coffee gets cold. We’re using the Genesys Cloud Real-time Speech API (v2.0) with the AudioHook connector, feeding into Cognigy.AI for agent assist. According to the documentation (https://developer.genesyscloud.com/reference/realtime-speech-api/audiohook), these should be resilient to network hiccups.

The WebSocket just…closes. No error code. Just gone.

{
 "event": "disconnected",
 "timestamp": "2024-02-29T14:37:12.123Z",
 "sessionId": "a1b2c3d4e5f6",
 "reason": ""
}

Spun up a quick Lambda to ping the NYC regional endpoint every 10 seconds, and it’s showing consistent 40-60ms latency. Feels like it’s not a straight network issue. Anyone else battling this, specifically from the East Coast? Might be a regional routing thing?

Hi all,

The disconnects - it’s like building a sandcastle with the tide coming in. You get a connection, everything looks good, then - poof - it’s gone. The root cause is almost always the WebSocket keep-alive timer on the Genesys Cloud side doesn’t match the expectations of Cognigy.ai. It’s a negotiation problem, a bit like two people speaking different speeds of French.

Here are a few things you can check:

  • WebSocket Timeout Configuration: You’ll need to adjust the timeout setting within your AudioHook configuration. The default timeout might be too short for your setup, especially if you are seeing latency issues. It’s a bit like giving a plant too little water - it will eventually wither. Check the maxWaitTimeSeconds parameter. Increase it - start with 60 seconds and see if it helps. You can check this in the developer portal.
  • Edge Location: The documentation mentions latency can impact AudioHook performance. We’re on Genesys Cloud, and sometimes the East Coast edge can have… issues. Try switching to a different edge location to see if that resolves the intermittency.
  • Cognigy.AI Configuration: Double-check that Cognigy.ai is configured to handle potential WebSocket disconnects and automatically reconnect. It needs a bit of resilience, you know? It’s similar to setting up a circuit breaker.
  • Managed Identity: Ensure your Azure Function (if you’re using one as a bridge, like we do) has the necessary permissions to access the Real-time Speech API. Three coffees into debugging this once and it was just missing permissions.

If nothing works, you might need to open a ticket with Genesys Cloud support, because it could be an infrastructure issue.

yeah so ripping on ’s point about the keep-alives - that’s almost always it (504). The documentation’s kinda vague, but it’s a heartbeat thing. You gotta poke Genesys every so often or it assumes you’re gone.

Here’s how the data’s supposed to flow:

[Cognigy] ----> [AudioHook] <---- [Genesys] 
 (audio stream) (WebSocket) (keep-alive)

But what’s happening is this:

[Cognigy] ----> [AudioHook] <---- [Genesys] 
 (audio stream) (WebSocket) (timeout!)

Took like 2 hrs to nail this last time. The fix is to add a ping interval on the Cognigy side - sending a no-op message to the AudioHook endpoint. Something like this in your Cognigy flow:

// Send a ping message every 10 seconds to keep the WebSocket alive
setInterval(() => {
 websocket.send("ping"); // 200, usually.
}, 10000);

You might need to tweak that 10 second interval - depends on your network, and how aggressively Genesys kills the connection (408).

genesyscloud-client-app-sdk handles the WebSocket connection by default with a 30-second keep-alive interval, unless you’re explicitly setting it. The suggestion above about keep-alives is right - Cognigy might need a different interval.

Try this: set the keepAliveIntervalSeconds option when you initialize the WebSocket. It’s in milliseconds, so 15000 is 15 seconds.

const sdk = require('genesyscloud-client-app-sdk');
const audioHookClient = new sdk.AudioHookClient({
 keepAliveIntervalSeconds: 15
});

Also, check the maxFrameSize parameter. We’ve seen issues when the payload is too big. The default is 16384.

const audioHookClient = new sdk.AudioHookClient({
 maxFrameSize: 8192 // try halving it
});

Terraform manages this setting via the keep_alive_interval_seconds attribute, so check that too if you’re using infrastructure as code. It’s pretty straightforward to change there.