IVR streaming for Contact Center

Use IVR (Interactive Voice Response) streaming to send real-time audio and event data from IVR flows to third-party applications. Use existing Realtime Media Stream (RTMS) webhooks to capture and process customer audio, SIP information, and DTMF input during automated call flows.

In addition to being assigned to the appropriate queue, RTMS apps should now be assigned directly to flows. When a customer calls a flow that has an app assigned to it and that app has auto-start enabled, data begins streaming automatically, earlier than it would with queue-assignment only.

Subflows inherit the app assignment from their parent flow.

Streaming behavior

RTMS sends a variety of data as part of a stream.

  • Send Media - audio prompts played to the customer
  • Collect Input - DTMF digits entered by the customer
  • Flow Enter / Flow Exit events
  • SIP information - data about the call. Sent in the contact_center.voice_rtms_started payload as the custom fields object

Flow and subflow logic

The main flow governs streaming for all its subflows. As long as the main flow is associated with an RTMS app, all subflows under it are streamed.

When a call is routed to another flow:

  • If the new flow has the same RTMS app, streaming continues and emits flow_exit and flow_enter events.
  • If the new flow does not have the app, agent and customer streams are both paused.

When a call is routed to another queue:

  • Agent streaming only happens if the queue is assigned the same RTMS app.
  • Customer streaming happens whether the queue is assigned the same RTMS app or not.

You can use custom scripts to configure flow routing logic.

Event types

IVR streaming introduces Contact Center voice events that provide real-time updates about call flow navigation, DTMF input, and queue operations. For complete event schemas and field definitions, see Contact Center events.

EventCodeDescription
IVR flow entered30Triggered when a call enters a new flow with the same RTMS app.
IVR flow exited31Triggered when a call leaves a flow.
DTMF input started / DTMF input ended32Both use event type 32. Captures DTMF digits pressed by the customer during input collection.
Queue waiting34Triggered when a call enters a queue. The data stream is paused until an agent joins the call.

Event logging

Enable console logging in your RTMS client to verify event flow.

This example prints all incoming RTMS events, including flow transitions and DTMF input.

websocket.on("message", (message) => {
    console.log("Event received:", message);
});

Configuration

To configure IVR streaming, create an RTMS app with the contact_center:read:rtms_ivr_stream:admin scope and assign your app to at least one flow. For more information on creating an app, see Add Realtime Media Streams features to your app. For information on assigning apps to flows, see Configuring Zoom Apps for Zoom Contact Center.

Any admin who adds your app to their account will have the ability to add flows to the app.

  • Once flows are added to the app, when the call enters the flow, the RTMS events will be generated and the IVR stream will be available to your app.
  • Only send media and collect input widgets are streamed. The rest of the stream will be silent until the call enters a queue.

Fraud detection apps

If your app is a fraud detection app and you require additional SIP headers to detect fraud, you should add the contact_center:read:zcc_voice_fraud_header:admin scope to your app. Once added, Zoom Contact Center will send the fraud detection SIP headers to your app.

HeaderFull nameWhat it means
PAIP-Asserted-IdentityNetwork-asserted caller identity. The originating carrier says "this is who is really calling," which can differ from spoofable From / ANI. Fraud apps treat this as a stronger identity signal than caller ID.
OLIOriginating Line InformationClass of the originating line (2-digit ISUP code). Examples: ordinary phone, payphone, prison, hotel/motel, cellular. Used to flag high-risk origination types.
JIPJurisdiction Information ParameterGeographic origin of the switch that launched the call, typically an NPA-NXX (area code + exchange). Used to compare claimed caller location vs. where the call actually entered the network.
RNRouting NumberNumber-portability routing number (LRN). The switch that currently owns the caller's number after porting. Helps detect port-out / neighbor-spoof patterns.
STIRSTIR/SHAKENCaller-ID attestation payload (Identity header). Shows whether the originating carrier signed the caller ID and at what trust level (full / partial / gateway). Weak or missing attestation is a spoofing signal.
DiversionDiversionThe call was forwarded or redirected before it reached you. Carries the original called number and redirect reason (unconditional, busy, no-answer, etc.). Used to tell a real forward from a spoofed/relayed call.
DNISDialed Number Identification ServiceThe number the customer actually dialed (the ZCC inbound number). Identifies which contact-center entry point was targeted; often paired with ANI (who called) as ANI/DNIS.