Skip to content

Test and troubleshoot

Test the path a caller uses: microphone or telephone audio through LiveKit and the configured providers. Deterministic tests and check are useful gates, not substitutes for a call.

Start a browser call

./scripts/check
./scripts/dev

Open http://localhost:3000, allow microphone access, and connect. In one short call confirm:

  • the worker accepts the room and the greeting plays first;
  • prepared caller data appears where expected;
  • participant speech is understood in the active language;
  • participant and assistant transcripts appear;
  • response audio starts within the bot's latency target;
  • qualifying barge-in stops obsolete assistant audio;
  • one authorized business tool reports an honest result;
  • end_call closes cleanly.

Use synthetic or approved test accounts. Do not put customer data in browser logs or bug reports.

Measure where time goes

Record these separately:

  1. end of participant speech → committed STT text;
  2. committed STT text → first model text;
  3. first safe model text → first TTS audio;
  4. end of participant speech → first audible response.

The fourth is caller-perceived latency. Compare the same phrase, region, route, and network. Streaming should overlap model output and TTS instead of waiting for a full answer.

Cover bot behavior

Test registered and unknown callers, every important prompt branch and tool, each language and switch direction, both silence nudges, a true and false interruption, configured fallback, transfer, tool/API error results, Judge output, transcripts, and the terminal result.

A development browser may combine only ready STT, LLM, TTS, language, and voice choices returned by the backend. Production has no selector. Confirm that unavailable or language-incompatible choices are disabled in the page and rejected by the token API.

Run a browser-room call before handoff. Before telephone traffic, run a separate inbound SIP call through the target number, trunk, dispatch rule, and transfer destination. Browser success does not prove SIP.

Capture safe evidence

When a call fails, record:

  • safe call and room IDs plus timestamp;
  • VAANI version, environment, and profile identity;
  • lifecycle phase and the slow or failing latency segment;
  • normalized provider/tool error;
  • whether participant audio, transcript, assistant text, and assistant audio existed.

Never attach credentials, raw provider payloads, or customer transcripts. Use the symptom guide in Troubleshooting, then finish the production checklist.