what does ivr_detection flag exactly do?

Thanks for reaching out, Harsh. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

But I have noticed that when ivr_detection is set True, there is an increase in latency when the human picked up the phone and not an IVR

Thanks — I’m responding to your observation that enabling

ivr_detection

increases latency when a human (not an IVR) picks up. Short answer: Enabling

ivr_detection

can add latency because extra detection steps run before the agent treats the call as a live human. Those steps can include audio analysis, silence/voice/activity checks, and possibly sending or awaiting DTMF interactions. That extra processing can delay the agent’s first prompt when a real person answers. What typically adds latency when `ivr_detection: True`: • Initial audio analysis — the system listens for patterns that indicate an IVR (tones, synthetic speech, long consistent silence, or playback characteristics) before starting normal dialogue. • Extended voice/activity checks — the agent may wait for a confirmation of human speech (or lack of IVR signatures) which takes extra milliseconds to seconds depending on thresholds. • DTMF probing or menu navigation — if the system tries small DTMF tests to validate or navigate an IVR, that introduces wait time. • Decision logic — after analysis, the agent decides whether to proceed as IVR or human; that decision step adds processing time. • Fallback or verification — if uncertain, the agent may perform additional verification checks which further delay the first interaction. How to investigate and reduce the latency: 1. Tell me which scenario you’re using (outbound campaign, predictive dialer, manual outbound call) and whether the latency affects the first prompt only or ongoing conversation. 2. Check and share the following settings (if you can): thresholds for voice/activity detection, any DTMF probing enabled, and the timeout values for IVR decision windows. 3. Try a short A/B test: ◦ Call with

ivr_detection: True

and log time from answer to first agent prompt. ◦ Call with

ivr_detection: False

and compare. This confirms the measurable difference and its magnitude. 1. If IVR detection is only needed for a subset of numbers, enable it selectively for those numbers to avoid global latency. 2. If your setup supports tuning, reduce the IVR detection window or lower the number of verification steps so the agent accepts human speech sooner (I can suggest exact parameters if you tell me which configuration options you have access to). 3. If DTMF probing is enabled, disable or shorten it for known human-targeted flows. If you share: • an example call flow or the specific config values you’re using, • and whether the latency is a few hundred milliseconds or multiple seconds, I’ll recommend concrete parameter changes and an optimized test plan to reduce the delay while keeping IVR detection reliable. , with interactive elements

I tried with ivr_detection set to true and false and found that with ivr detection enabled, the latency is indeed high

Thanks — I’m following up on your test where you confirmed higher latency with

ivr_detection: True

. I appreciate you running the experiment; that helps narrow the cause. Why you’re seeing higher latency (brief recap) • With

ivr_detection

enabled, the agent runs extra detection steps (audio analysis, voice/activity checks, possible DTMF probing, and decision logic) before treating the answer as a human. Those checks add measurable delay compared with skipping IVR detection. Practical next steps to reduce latency while keeping IVR detection 1. Narrow where IVR detection runs ◦ Only enable

ivr_detection

for number ranges, campaigns, or flows that commonly reach IVRs. Turning it off for known human-targeted calls removes the extra overhead entirely. 1. Shorten the IVR decision window ◦ Reduce the time the system listens before deciding. Lowering the detection timeout shortens the wait before the agent starts speaking (I can suggest specific timeout values if you share current settings). 1. Relax verification thresholds ◦ If your config has parameters for required voice activity or confidence thresholds, lowering them lets the system accept a human earlier. This trades a little detection sensitivity for lower latency. 1. Disable or limit DTMF probing ◦ If the system sends DTMF probes to detect or navigate menus, disable probes for human-focused flows or shorten the probe sequence and response timeout. 1. Use a quick heuristic first-pass ◦ Have the system perform a lightweight, fast check (e.g., check for immediate synthetic-speech signatures or long continuous playback) and only run the full IVR analysis if that first-pass is uncertain. 1. A/B test tuned parameters ◦ Run controlled A/B tests with incremental changes (shorter timeout, lower thresholds, no DTMF) and measure answer-to-first-prompt latency and IVR-detection accuracy to find the best balance. What I need from you to give concrete values • Which outbound flow are you using (campaign, predictive dialer, manual outbound)? • Current IVR-related settings you can access (detection timeout, voice-activity thresholds, whether DTMF probing is enabled, any confidence thresholds). • Typical magnitude of the extra latency you measured (e.g., +300 ms, +2 seconds). • Whether false negatives (missing IVRs) or false positives (treating IVR as human) are more harmful for your use case. If you share those details I’ll recommend exact parameter changes and a short test plan (step-by-step) to reduce latency while keeping IVR detection effective. , with interactive elements