DialNexa Retries Transfers And Audio Cache Monitoring

Monitor DialNexa retry history, transfer sessions, transfer legs, transfer statuses, and Audio Cache details from the call detail experience.

Retries, Transfers, and Audio Cache monitoring explain special behavior around a call. Retry history explains repeated attempts, Transfers explains human handoff sessions, and Audio Cache explains whether repeated speech was looked up or reused.

When a call has special behavior, the transcript is chapter one. The extra tabs are where the plot twists live.

Monitor DialNexa Retries Transfers And Audio Cache

Area	Evidence	Use it when
Retries	Parent call id, attempt rows, retry status, timing, billing where available, and final result.	A recipient was called more than once.
Transfers	Transfer sessions, representative legs, bridge state, timing, and failure reason.	The agent attempted a human handoff.
Audio Cache	Cache status, hit rate, lookups, hits, misses, and new cache entries.	Repeated phrases felt fast, slow, or inconsistent.

Audio Cache Metrics

The call detail Audio Cache tab reads the cache summary stored on the call when available.

Metric	Meaning
Cache Status	Whether Audio Cache was enabled for the call.
Cache Hit Rate	Percentage of lookups that reused cached audio.
Lookups	Number of cache checks for repeated text-to-speech segments.
Hits	Number of times DialNexa reused cached audio.
Misses	Number of times no matching cached audio existed.
New Cache Entries	Number of new synthesized segments stored for future reuse.

If Audio Cache was disabled, the UI can still label some numbers as potential cache behavior when data exists. That helps users see whether a repeated script would likely benefit from turning it on.

DialNexa stores new cache entries only after a synthesized segment is complete enough to reuse. Interrupted, aborted, or mismatched segments are delivered to the current call when possible, but skipped for cache storage so a future caller does not hear partial audio for a full sentence.

Why Cache Misses Happen

Cause	Example
Dynamic variables	”Hi Rohan” and “Hi Priya” are different generated phrases.
Model wording changed	The LLM says the same idea using different words.
Voice configuration changed	Different provider, voice, voice model, speed, stability, volume, or output format.
Long custom replies	Long responses usually vary too much to repeat exactly.

Transfer Evidence

Transfers should be reviewed as sessions, not just as a transcript moment.

Evidence	What it explains
Transfer session status	Whether handoff reached a final transfer state.
Representative leg	Whether the destination answered, failed, or timed out.
Bridge status	Whether caller and representative were connected.
Failure reason	Why the handoff did not complete.
Timing	Whether the transfer waited too long or failed quickly.

Investigate A Special Call

1. Open the original call row

   Keep route, agent, batch, workflow, and call id context together.

2. Check retry history

   If the call came from a batch, inspect attempts before judging the final recipient outcome. For current-billing workspaces, retry rows can include the charged amount and billed duration for each attempt.

3. Open Transfers

   Review session state, representative leg state, bridge behavior, timing, and failure reason.

4. Open Audio Cache

   Review cache status, hit rate, lookups, hits, misses, and new cache entries.

5. Fix the owning setting

   Change retry rules, transfer configuration, voice setup, or Speech Settings based on evidence.

Related Reading

Retries And Statuses

Configure campaign retries.

Call Transfer

Configure handoff behavior.

Text To Speech

Understand cache-friendly speech.

Call Detail Page

Read the complete call evidence.