AI in Webex
BYoVA WebSocket: Audio, DTMF, and Barge-in Flows
Understand the BYoVA WebSocket audio profile, response timing, caller barge-in, and DTMF collection behavior.
anchorOverview
anchorUse this page with the BYoVA over WebSocket guide, which defines the full conversation contract. The media profile below reflects the current Webex Contact Center integration guidance.
anchorAudio format
anchor| Property | Current integration profile |
|---|---|
| Encoding | G.711 mu-law, also called PCMU or u-law |
| Sample rate | 8000 Hz |
| Channels | One, mono |
| Sample size | 8 bit, one byte per sample |
| Container | None; audio content is raw and has no WAV or RIFF header |
| JSON encoding | Base64 in the audio field |
Webex sends caller audio in audio_input.caller_audio_b64. The partner returns audio in prompts[].audio_content_b64. Use the encoding and sample rate in the request, and do not add container headers to the raw media payload.
anchorStream response audio
anchorUse CHUNK messages for streamable response audio. Send PARTIAL messages for intermediate state or transcript information only when the request sets allow_partial_responses to true. That flag governs PARTIAL; CHUNK follows the separate audio-streaming behavior. Send exactly one FINAL to close each logical reply. A streamed response carries raw, headerless G.711 mu-law bytes in its audio fields. FINAL can be audio-less; do not send another response for the same reply after it.
| Fragment size | Guidance |
|---|---|
| Minimum | 320 bytes (40 ms at 8 kHz, mono, 8-bit) |
| Practical recommendation | 8000–16000 bytes (about 1–2 seconds) |
| Maximum | 32 KB |
Send each fragment as soon as it is generated. Webex buffers and schedules partner audio for playback, so do not pace transmission to match playback duration. If a speech engine produces frames smaller than the minimum, aggregate them until the fragment reaches the minimum, then flush.
anchorSpeech boundaries and barge-in
anchorThe partner detects the beginning and end of caller speech and reports those boundaries to Webex:
- Send
START_OF_INPUTwhen the partner detects caller speech. - Send
END_OF_INPUTwhen the partner's endpointing or end-of-turn logic considers the input complete.
Without barge-in, Webex starts the next caller-audio stream only after it receives the response FINAL; speech during playback is not delivered to the partner. To let the caller interrupt a prompt, set prompts[].is_barge_in_enabled to true and send START_OF_INPUT when new caller speech is detected. The WebSocket contract has no separate BARGE_IN event.
anchorDTMF collection
anchorWebex delivers DTMF as one ordered dtmf_events collection, not one request per key. Process the digits in order. Collection ends when the configured terminator is entered, the requested maximum length is reached, or the inter-digit timeout expires.
Use input_mode and input_handling_config.dtmf_config in the partner response to configure the next input. The no-input timer applies before the first voice or DTMF input; the inter-digit timer applies after digit entry begins. Configure the digit limit, terminator, and timeout explicitly for the intended flow.
START_OF_DTMF is a Webex-to-partner event associated with DTMF input. In a non-barge-in DTMF turn, Webex starts the next input after FINAL; with barge-in enabled, the first audio-bearing response also controls when the next input stream starts.