Call handling properties

AudioCodes VoiceAI Connect exposes several call-handling properties on the bot and as mid-call overrides. Delphi maps the ones that exist today onto provider / flow configuration. This page is the shared reference; fill remaining rows as those stories land.

Segmentation silence timeout (SCRUM-698)

segmentationSilenceTimeoutMs (VAIC: sttSegmentationSilenceTimeoutMs) is how long Azure STT waits on non-speech before it finalizes the current utterance. Valid range on Azure is typically 100–5000 ms.

Surface	Status
Flow Designer → default / node STT provider config	Shipped (segmentationSilenceTimeoutMs)
Azure STT query / session option	Shipped
Mid-call TOBi config / runtimeCommand override	Shipped. Bot sessionParams last-value-wins; missing keys keep the current recognizer timeout

The bot can change the timeout during a call with a config custom event. Accepted sessionParams names (first present wins): sttSegmentationSilenceTimeoutMs (VAIC), azureSpeechSegmentationSilenceTimeoutMs (deprecated VAIC), segmentationSilenceTimeoutMs (Delphi). Valid range 100–5000. TelPhi merges the value into the live Azure STT config and resets the recognizer so the next WebSocket session and speech.context use the new timeout.

Barge-in (SCRUM-695)

For modular flows with the managed TOBi LLM, three properties control whether caller input interrupts bot playback. Each can be set as a bot default (Flow Designer → managed TOBi → DTMF & speech section) and changed mid-call by the bot via a config custom event with sessionParams — last value wins, missing keys keep the current value (VAIC semantics).

Property	Default	Effect
bargeIn	true	Master switch. When false, neither speech nor DTMF interrupts bot playback.
bargeInOnDTMF	true	DTMF digits interrupt playback (requires bargeIn and DTMF forwarding to be enabled).
bargeInMinWordCount	1	Caller speech interrupts playback only once this many words have been recognized. Applies to partial results too, so interruption stays responsive.

Flows without the managed TOBi LLM (plain modular, realtime) keep the default behavior: caller speech always interrupts playback.

Interruption prevention (SCRUM-410)

To prevent callers from interrupting the bot — for example during a legally required announcement — set bargeIn: false (as a bot default or mid-call via the config event) and re-enable it afterwards. Mid-call sessionParams apply immediately when the config event arrives; they are not queued behind the following TTS prompt. Put bargeIn: false in the same callback as the announcement (or send it just before) so speech and DTMF cannot barge that prompt. This is the supported interruption-prevention mechanism. VAIC's separate persistentRecognition property is not implemented; if VF needs recognition to keep running while interruption is blocked, that is a follow-up story.

Continuous ASR (SCRUM-694)

When enabled, recognized utterances are batched and sent to TOBi as one combined message instead of one message per utterance — useful when callers speak in bursts (say a customer number, pause, continue). Matches the VAIC behavior of the same name.

Property	Default	Effect
continuousASR	false	Enables utterance batching.
continuousASRTimeoutInMS	3000	Silence after the last utterance before the batch is sent (500–60000 ms).
continuousASRDigits	#	DTMF key that sends the batch immediately. The key is consumed (not treated as DTMF input). Empty string disables the key.

All three are available as bot defaults in the Flow Designer and as mid-call sessionParams overrides. Batched speech still respects the barge-in rules above: the combined recognized text counts toward bargeInMinWordCount while the bot is speaking.

VAIC's continuousASRHypothesisTimeoutInMS and continuousASREmptyUserInputText are not implemented.

:::note Architecture Continuous ASR is implemented in the voice gateway (TelPhi) on the text output of speech recognition — it hooks the generic STT transcription callback and is therefore STT-provider-agnostic, exactly like VAIC. It does not touch the audio path: the optional audioproc container only processes raw audio (denoising) before it reaches the STT engine and stays uninvolved. No additional container is required for this feature. :::

Silence & speech detection (SCRUM-690)

When enabled, the voice gateway (TelPhi) runs a voice-activity detector on the caller's audio and forwards audio to the STT provider only while speech is in progress. The STT connection stays open the whole time — during detected silence the audio feed is simply paused, which reduces billable STT audio and avoids recognitions triggered by line noise. This matches VAIC's speechDetection behavior.

Unlike barge-in and continuous ASR, these properties are admin-only flow defaults (Flow Designer → managed TOBi → DTMF & speech section). They are deliberately not exposed as mid-call sessionParams overrides, mirroring VAIC where they are administrator parameters.

Property	Default	Effect
speechDetection	disabled	disabled sends all audio (pre-690 behavior). enabled gates the STT feed on detected speech. on-bot-prompt additionally keeps the gate closed while the bot prompt plays.
speechDetectionEngine	auto	Detector behind the gate (SCRUM-891): auto, energy, or silero — see engine table below.
speechDetectionSilencePeriodMS	500	Sustained silence after a final transcription before the STT feed pauses (10–10000 ms).
sttNoSpeechTimeoutMS	0	Force-closes the gate when detected sound (e.g. background music) never yields a transcription within this window (0–60000 ms). 0 disables the guard.

Speech-detection engines

Two detectors are available behind the same gate (SCRUM-891); only the classifier differs — pre-roll, close rules, and all timers behave identically:

Engine	Where it runs	Quality	CPU cost	Requirement
energy	In-process (TelPhi)	Detects sound, not speech — hold music or steady background noise keeps the gate open (RMS level with hysteresis)	Negligible (~a few µs per 20 ms frame)	None
silero	audioproc container (Silero VAD neural model via ONNX)	Distinguishes speech from music/noise/tones — better savings on noisy lines and no false gate-opens from hold music	Runs in the separate audioproc container, not on the gateway	The flow must have audio preprocessing enabled (same container that does RNNoise/DeepFilterNet denoising)

auto semantics (default): the gate uses Silero when the call has a connected audioproc session with VAD confirmed, and the energy detector otherwise. Enabling audio preprocessing on the flow is what turns Silero on — no separate switch needed.

Fallback behavior — availability over quality: a broken container degrades detection quality, never the call. Silero classifies after denoising inside the container and streams speech/silence decisions to TelPhi as control messages; the container never drops audio, TelPhi remains the only component that gates the STT feed. TelPhi keeps an energy detector warm on every frame and takes over automatically when:

• the container refuses VAD at session start (e.g. missing model) or the flow has no audioproc session — with speechDetectionEngine: silero this logs a vad_engine_fallback warning;
• the container goes quiet mid-call (no messages for >2 s) — a frozen "silence" decision can never suppress caller speech;
• the container reconnects — Silero takes over again seamlessly.

Behavior details:

• No clipped onsets — while the gate is closed, the last ~400 ms of audio are kept in a pre-roll buffer and flushed to STT the moment speech is detected, so word beginnings are never lost.
• Safe end-of-utterance — the gate never closes mid-utterance. Audio keeps flowing until the STT provider has returned a final transcription and the configured silence period has elapsed (STT endpointing is audio-clock based, so cutting the feed earlier would break utterance finalization).
• Barge-in keeps working — in enabled mode caller speech opens the gate even while the bot is speaking, so the barge-in rules above apply unchanged. Use on-bot-prompt on lines with echo/loudspeaker issues where prompts falsely trigger recognition; DTMF barge-in is unaffected either way.
• Continuous ASR compatible — the gate operates on audio upstream of speech recognition; utterance batching (SCRUM-694) operates on recognized text downstream and combines cleanly.

Observability: TelPhi logs vad_gate_open / vad_gate_close (with close reason) per transition and a per-call vad_gate_summary at teardown with forwardedMs, suppressedMs, suppressedPercent, and gateOpens — the evidence that STT usage actually dropped. All three events carry an engine field (energy, silero, or silero_fallback_energy when the container fallback is active) so savings can be compared per engine; vad_engine_selected records the choice at gate creation.

VAIC's stopSttOnMessageToBot is deferred, and sttSpeechActivityMode is not applicable (Google-STT-only property).

Later properties

Property	Ticket	Status
Media give-up / no incoming RTP	SCRUM-700	Parked
stopSttOnMessageToBot	—	Deferred
persistentRecognition	—	Not implemented; bargeIn: false is the interruption-prevention mechanism

See also

• Managed callback actions — hangup / transfer / config events
• Speech playback