Browser-local stream-media preparer
Twilio Media Streams μ-law Audio Preparer
Audio sent back to a Twilio bidirectional Media Stream must be base64-encoded "audio/x-mulaw" at 8,000 Hz. The payload must contain raw audio bytes rather than WAV or other file headers. IVRReady prepares WAV source audio into that stream-ready payload locally in your browser.
Scope: audio sent from your application to Twilio during a bidirectional <Connect><Stream> Media Stream.
IVRReady does not open a WebSocket, place a call, connect to Twilio, or send media. It prepares local artifacts for your runtime application.
Media source workspace
Add WAV sources to check against the Twilio Media Streams profile.
Prepare Twilio Media Streams media
Drop WAV files, folders, or ZIP packages
Quality checks
IVRReady QA preferences — these are not target-platform requirements.
Off by default. Trimming modifies your audio, so enable it only when you intend to change the recordings.
Outbound Media Streams contract
This is a stream-media target, not an uploadable prompt-file target. The Twilio payload has no container and must already be raw mono μ-law at 8 kHz before the developer’s application sends it.
| Requirement | Documented value |
|---|---|
| Stream type | Bidirectional "<Connect><Stream>" |
| Media encoding | audio/x-mulaw |
| Sample rate | 8,000 Hz |
| Channels | Mono |
| Transport payload | Base64 media.payload |
| File/container header | Must not be included |
| Payload size | Twilio documents any size; browser and IVRReady safety limits still apply |
| IVRReady source input | WAV |
Why can’t I send my μ-law WAV directly?
A μ-law WAV contains RIFF/WAVE, format-chunk, and data-chunk headers. Twilio’s media.payload expects only the raw μ-law bytes from inside the WAV data chunk. IVRReady locates that chunk structurally, extracts its exact payload, and base64-encodes it without assuming a 44-byte header.
Ready, Fixable, and Error
- Ready
- The source WAV already contains 8 kHz mono μ-law audio. IVRReady strips the WAV container and builds the payload without audio transcoding or FFmpeg.
- Fixable
- The verified source layout needs downmixing, resampling, and/or μ-law encoding. The generated canonical WAV is reinspected before raw extraction.
- Error
- The WAV cannot be safely inspected or transformed. QA warnings remain separate IVRReady signal policies.
Generated package
Each source produces a headerless media/*.ulaw file and a matching messages/*.media.template.json file containing the actual base64 payload. Replace MZ_REPLACE_AT_RUNTIME with the active Stream SID received at runtime before sending the message.
Payload size, buffering, and marks
Twilio’s Media Streams documentation says the outbound media payload can be any size and buffers media messages in received order. Practical browser memory and IVRReady safety limits still apply. IVRReady creates one payload per source and does not invent 20 ms, 160-byte, duration, or payload-size requirements. Applications can send a mark message after media when they need confirmation that buffered audio has finished playing.
Scope boundaries
This pack does not cover TwiML <Play>, recordings, unidirectional Media Streams, media received from Twilio, Voice SDK playback, ConversationRelay, SIP codecs, credentials, signature validation, live calls, or WebSocket state.