important-judge-78504
05/11/2026, 5:06 PMtall-airline-16756
05/11/2026, 5:06 PMtall-airline-16756
05/11/2026, 5:06 PMsend_dtmf_events tool and options you can try.
• Fact: send_dtmf_events sends tones sequentially with a 0.3s delay between events (DEFAULT_DTMF_PUBLISH_DELAY). This delay exists to ensure reliable delivery to telephony providers and the tool will stop on the first send failure. (send_dtmf_events doc: https://docs.livekit.io/agents/prebuilt/tools/send-dtmf-events/)
Options to try
• Quick check: If you’re using send_dtmf_events, confirm whether a single combined sequence (e.g., sending the full key string in one call) fits the IVR window—this avoids repeated call overhead.
• Reduce network latency: Place the agent/server as close as possible to the telephony endpoint (or use a region closer to the PSTN gateway) to shrink end-to-end delay.
• Custom DTMF publisher: Implement custom logic with the lower-level LiveKit APIs to publish DTMF events with shorter spacing than 0.3s. The prebuilt tool’s delay may not be configurable, so custom publishing can achieve tighter timing—note you’ll need to handle retries/errors since the tool’s built-in safety will be absent.
• Timing strategy: If the IVR accepts a single-digit “confirm” followed by a pause, try sending critical digits earlier in the call flow, or pre-send harmless digits to keep the channel ready then send the key when the IVR opens.
• Test and log: Run timed tests against the target IVR to find the minimum reliable inter-digit delay and implement that in your custom sender.
Quick question to narrow advice: Are you currently using the prebuilt send_dtmf_events tool or a custom implementation? If custom, which SDK/language are you using?
Sources: send_dtmf_events | LiveKit Documentation, with interactive elementsimportant-judge-78504
05/11/2026, 5:07 PMtall-airline-16756
05/11/2026, 5:08 PMpublish_dtmf immediately for simple IVR prompts without a full LLM pass.
• Instrument & measure: use agent observability to measure STT, LLM, and tool call durations and find the biggest bottleneck to target.
Trade-offs to be aware of
• Preemptive/partial transcription and faster models can reduce accuracy; you may need retries or fallbacks.
• Custom short-circuit logic reduces LLM latency but increases maintenance for IVR edge cases.
One quick clarifying question: are you able to stream partial STT results into the LLM today, or is your pipeline currently waiting for a final transcript before calling the model?
Sources: Understand and Improve Agent Latency | LiveKit | Voice Agent Architecture: STT, LLM, and TTS Pipelines Explained | LiveKit | Understand and Improve Agent Latency | LiveKit | send_dtmf_events | LiveKit Documentation | Sequential Pipeline Architecture for Voice Agents | LiveKit, with interactive elements