Skip to main content

​
Test a WebSocket endpoint

Open a WebSocket to your server and send exactly what a real call sends: one start frame, then a media frame every 20 ms for --duration seconds, then one stop frame. Reports connection latency, frames sent, and (with --bidirectional) whether your server sent audio back. No call is placed and Plivo’s backend is not involved; this is a pure client-side check you can run in CI.

​
plivo voice streams test

Pre-flight a WebSocket endpoint with synthetic Plivo audio frames Command:
Flags
  • --bidirectional: also read frames back from the endpoint (test bot→caller path)
  • --codec <string>: audio codec: mulaw | l16 (default “mulaw”)
  • --duration <int>: seconds of synthetic audio to stream (max 30) (default 3)
  • --insecure: skip TLS verification (self-signed dev certs only)
  • --rate <int>: sample rate in Hz (mulaw: 8000; l16: 8000 or 16000) (default 8000)
  • --to <string>: WebSocket URL of the endpoint to test (ws:// or wss://, required)
Examples
If Received N frames back from endpoint is missing with --bidirectional, your server never sent a playAudio message: callers would hear silence.

​
The audio contract

The XML attribute and the WebSocket frame spell the audio format differently, which is the part that is easiest to get wrong. <Stream> carries a single combined contentType attribute holding the codec and the sample rate together. There is no sampleRate attribute on <Stream>.
The WebSocket start frame spells the same two things out separately, under mediaFormat:
The l16 MIME type is audio/x-l16, not audio/l16. Exactly three combinations are supported: There is no mu-law 16 kHz stream. Any other codec and rate pair is rejected before the connection is opened, with BAD_FLAG and exit code 1, so a bad combination fails on your laptop instead of as a dropped stream mid-call. --codec l16 generates real little-endian 16-bit PCM, so a bot that decodes the payload sees a genuine waveform rather than mu-law bytes under an l16 header.