Input Events (Plivo to Your Server)
These events are sent from Plivo to your WebSocket server.start
Sent once when the stream begins. Contains call and stream metadata.
media
Sent continuously during the call. Contains audio data from the caller.
Audio Chunk Details:
- Each chunk contains approximately 20ms of audio
- At 8kHz with mu-law encoding: ~160 bytes per chunk
- Decode using:
Buffer.from(payload, 'base64')
dtmf
Sent when the caller presses a key on their phone.
playedStream
Confirmation that audio with a checkpoint has finished playing.
clearedAudio
Confirmation that the audio queue has been cleared.
Output Events (Your Server to Plivo)
These events are sent from your WebSocket server to Plivo.playAudio
Send audio to be played to the caller. For bidirectional streams only.
Important: The content type and sample rate must match what was specified in your Stream XML.
checkpoint
Mark a point in the audio queue. Receive a playedStream event when playback reaches this point.
Use Cases:
- Track when a specific response finishes playing
- Coordinate actions after audio playback
- Measure time from sending audio to playback completion
clearAudio
Clear all queued audio. Use this to implement interruption.
sendDTMF
Send DTMF digits into the active call. Use this to navigate external IVR menus, enter PINs, or trigger touch-tone actions during a bidirectional stream.
Use Cases:
- Navigate external IVR systems programmatically
- Enter PINs or account numbers during a call
- Build AI-powered agents that interact with touch-tone menus
Stream Status Callback Events
These events are sent to yourstatusCallbackUrl via HTTP.
started
Sent when the WebSocket connection is successfully established.
stopped
Sent when the stream ends normally.
failed
Sent when the stream fails to start or encounters an error.
JSON Schema
Complete JSON Schema for all Plivo Stream events.TypeScript Types
Complete TypeScript type definitions for all Plivo Stream events.Manual Signature Validation
If you need to implement signature validation without an SDK:Advanced Voice AI Patterns
Voice Activity Detection (VAD) and Turn Detection
The Challenge: Knowing when the user has finished speaking. Approaches:-
Silence-based VAD: Wait for N milliseconds of silence
- Pros: Simple
- Cons: Slow, doesn’t handle pauses well
-
STT End-of-Speech Detection: Most STT services provide
speech_finalevents- Pros: Understands speech patterns
- Cons: Slight delay
-
Semantic Turn Detection: Use LLM to determine if response is needed
- Pros: Handles complex dialogue
- Cons: Added latency
speech_final with a short timeout (300-500ms).
Interruption Handling
Users should be able to interrupt the AI mid-response.Context Management
Maintain conversation context for coherent multi-turn dialogue:X-Headers for Dynamic Agent Selection
Additional Stream XML Examples
Basic Unidirectional Stream (Listen Only)
Higher Quality Stream (16kHz)
Record After Stream
Best Practices Summary
Hosting Recommendations
Cloud Providers with Low-Latency Options:
Optimization Tips:
- Use the same region as your AI services when possible
- Deploy WebSocket servers in multiple regions for global traffic
- Use connection pooling for AI service clients
- Keep WebSocket handlers lightweight—offload heavy processing
Last updated: January 2026