AudioHook Integration Dropping Media Stream When Edge Server Handles DTMF Collection

We are implementing an AudioHook integration to stream real-time call audio to our on-premise speech analytics platform. The integration works correctly for the majority of calls. However, we have identified a consistent failure pattern: the AudioHook WebSocket connection drops and does not recover whenever the Architect flow enters a Collect Input block that uses DTMF collection on an Edge-handled call.

The behavior is specific to our BYOC Premises deployment where the Edge appliance handles media. Calls routed through Genesys Cloud Voice (non-Edge) do not exhibit this issue. The AudioHook stream remains stable through the entire call lifecycle on cloud-media calls, including DTMF collection.

Edge server details:

  • Model: Genesys Edge 520
  • Firmware: 1.0.0.9823
  • Media tier: configured for local media processing
  • AudioHook connector version: 2.1.4

The WebSocket close event shows code 1006 (abnormal closure) with no reason string. The close occurs within 200ms of the Collect Input block executing in the Architect flow.

Has anyone successfully maintained an AudioHook stream through DTMF collection on Edge-managed calls?

This is a known limitation in the Edge firmware for AudioHook with local media processing! When the Edge handles DTMF collection locally (RFC 2833 or in-band), it temporarily reconfigures the RTP media stream to insert the DTMF detection DSP into the audio pipeline. This reconfiguration tears down the existing media fork that feeds the AudioHook WebSocket.

The fix is available in Edge firmware 1.0.0.10142 and later. The updated firmware maintains the AudioHook media fork as a separate audio tap that is unaffected by DTMF DSP reconfiguration.

If upgrading firmware is not immediately possible, the workaround is to change the DTMF collection method from local Edge processing to cloud-based processing. In your Architect flow, before the Collect Input block, add a Set action:

Set Flow.dtmfMethod = "cloud"

Then in the Collect Input block properties, set the “DTMF Processing” to “Cloud.” This routes the DTMF detection through the Genesys Cloud media service instead of the Edge DSP, which leaves the Edge media fork intact.

The trade-off is slightly higher DTMF detection latency (50-100ms additional round-trip to cloud), but the AudioHook stream remains uninterrupted.

The firmware upgrade is the real fix. Just want to add some context on the AudioHook rate limits that are relevant when you have this working.

Each AudioHook integration has an undocumented concurrent stream limit of 200 simultaneous WebSocket connections per org. If your contact center handles more than 200 concurrent calls, the 201st call will not get an AudioHook stream - it silently fails to establish the WebSocket without any error in the Architect flow.

You can monitor your current AudioHook stream count via the Platform API:

GET /api/v2/integrations/speech/audiohook/{integrationId}/status

The response includes activeStreams and maxStreams fields. If you are consistently hitting the limit, you need to request a limit increase through your Genesys account team. They can bump it to 500 or 1000, but it requires a backend configuration change on their side.