Voice AI Audio Compatibility: A 12-Case Phone/Web Acceptance Test

Decision in one minute

Do not approve a phone voice agent because its browser demo sounds clear, because a vendor says “we support 8 kHz,” or because one test call completed. Approve the path only after you can name the representation at every boundary, observe what actually crosses that boundary, and pass a small compatibility suite on the real phone and browser routes you intend to support.

The distinction that prevents most avoidable audio defects is this: a sample rate is not a codec, a codec is not a container, and metadata is not a conversion. Relabeling 48 kHz samples as 8 kHz does not resample them. Base64 is an encoding of bytes for transport; it does not make those bytes μ-law, A-law, PCM, or Opus. A WAV header is useful in a file, but a streaming API that asks for raw codec bytes may treat those header bytes as sound.

For a Twilio bidirectional Media Stream, the contract is explicit: the start.mediaFormat reports audio/x-mulaw, 8,000 Hz, one channel; outbound audio is raw μ-law at 8,000 Hz, Base64 inside a text JSON WebSocket message, with no audio-file header. Twilio’s WebSocket message reference is the authority for that product-specific contract. It is not a universal rule for every carrier, SIP trunk, WebRTC session, or voice-agent provider.

This article supplies a reusable 12-case acceptance suite, a boundary manifest, a minimal executable metadata validator, and a release decision. The tests are deliberately designed to detect contract mistakes before people judge a voice model. They do not claim to measure speech recognition accuracy, subjective naturalness, or end-to-end service quality.

Why one good demo is not a compatibility test

A browser demonstration normally exercises a browser microphone, a browser media stack, and whichever network path the demo team configured. A phone call can add a carrier, a PSTN or SIP edge, a media gateway, a streaming protocol, an adapter, a resampler, a speech service, and an outbound playback path. Those components may each accept a different representation. If one component silently converts audio, the next component may receive an output different from the format label that the application believes it sent.

The user-visible symptoms are misleading. A wrong sample rate can sound faster, slower, higher, or lower in pitch. A wrong companding law can sound harsh or badly distorted. A channel-count error can make one side silent or make a decoder interpret interleaved samples as a single stream. A file header in a raw media payload can produce a short click, a garbled opening, or a broken first word. A JSON envelope sent as a binary WebSocket frame can fail before audio decoding even begins. The same symptom can have several causes, so “the voice sounds bad” is a report, not a diagnosis.

The WebRTC codec guide from MDN describes G.711 as 8-bit samples at 8 kHz and distinguishes A-law from μ-law; it also cautions that browser codec support varies beyond the mandatory set. MDN’s codec reference is useful for understanding a browser endpoint, but it does not specify a telephony vendor’s WebSocket message format. Likewise, the Twilio contract does not define what a separate WebRTC peer or model API must accept.

That distinction matters operationally. A service may correctly convert 48 kHz floating-point microphone frames to 24 kHz signed PCM for a model, then convert model output to μ-law for a phone gateway. A defect can sit in either conversion, in framing, in channel mixing, or in the envelope. A happy-path demo tells you only that one particular combination worked once. It does not tell you which combination ran, whether the gateway converted it, or whether the payload label matched the bytes.

The decision this protocol resolves

Use this protocol when choosing between two practical actions: accept an AI phone-agent integration for a defined production route, or keep it in a controlled test environment until its media contract is known. It is especially useful when a vendor says that phone and browser “use the same audio,” when different sample rates appear in logs, when a recording is clean but a live call is distorted, or when a team cannot explain where resampling occurs.

The answer is not “always convert everything to 8 kHz.” The answer is “select the contract required by each adjacent endpoint, then make each conversion explicit and observable.” A phone platform may require narrowband audio. A model may require linear PCM at a higher rate. A browser peer may negotiate Opus. A bridge can support all three, but only if it records the input representation, the transformation, the output representation, and the failure behavior at each boundary.

The public information baseline is already strong on individual formats. Twilio documents its message envelope and raw outbound μ-law payload. MDN describes WebRTC codec options. SignalWire documents its own stream choices, including PCMU, A-law and linear PCM options, and distinguishes phone streams from browser WebRTC. Its details are product-specific; they are evidence that products can differ, not a reason to assume any other provider behaves the same. SignalWire’s call-streaming guide is a useful counterexample to a universal “phone audio is always 8 kHz μ-law” assumption.

What those references do not hand a buyer is a compact, vendor-neutral checklist that proves the actual bytes, channel layout, framing, and conversion ownership on the route they are about to launch. That is the gap addressed here. The proposed cases are engineering test vectors, not a performance study. No success rate, defect prevalence, or customer-impact figure is inferred from them.

Establish the contract before listening

Write one row for each boundary, not one row for the entire product. “The agent uses 24 kHz” is incomplete if the phone gateway speaks μ-law at 8 kHz and the browser uses negotiated RTP codecs. The contract needs both the producer’s output and the consumer’s input, plus who performs any conversion between them.

Boundary	Record before testing	What must be observed	Release condition
Phone provider → adapter	Provider, stream direction, codec, rate, channels, framing and envelope	Start metadata and a captured message type	Runtime metadata matches the route’s declared profile
Adapter → speech model	Model endpoint, encoding, rate, channel layout and sample format	Bytes after decode and immediately before send	Conversion is explicit; endpoint receives its documented format
Speech model → adapter	Model output format and chunk semantics	Response metadata and chunk payload	Output is decoded according to the model contract, not guessed
Adapter → phone playback	Phone codec, rate, channels, message format and file-header policy	The exact outbound frame type and decoded sample count	Provider receives the right envelope and raw audio bytes
Browser → WebRTC peer	Browser, negotiated codec, clock and channel layout	Session description / negotiated codec and track metadata	Negotiation, fallback and browser matrix are documented
Recording / observability sink	Container, codec, rate, channels and timestamp origin	File probe plus saved metadata	The recording is labelled as recorded, not as source audio

The row should contain concrete values, not words such as “standard,” “HD,” “telephony quality,” or “real time.” A contract is executable only when an operator can compare it with a packet capture, stream metadata, or decoded buffer. If a component hides that evidence, document the limitation and add an observable test point before that component is accepted.

Keep the terms separate

Sample rate counts samples per second. It does not tell you the encoding. Sample format describes a decoded sample representation such as signed 16-bit integer or floating point. Codec defines how audio is represented or compressed. Container packages one or more streams and may include headers and metadata. Transport framing describes how messages or packets are carried. Channel layout states whether there is one channel, two channels, or multiple labelled channels. These are separate fields in the contract.

G.711 is a family with μ-law and A-law variants. Both use 8-bit companded samples in common telephony use, but they are not interchangeable labels for the same bytes. The MDN guide notes the two laws and describes the poor playback that can result when one is decoded as the other. That is a codec mismatch, not a sample-rate mismatch. The WebRTC requirements are described more formally in RFC 7874, which identifies PCMA and PCMU support requirements and the role of negotiated codecs. A browser’s ability to implement a codec does not prove that a specific application negotiated or sent it.

Base64 only maps binary bytes into text-safe symbols. It is not an audio codec and it does not repair wrong bytes. When a protocol asks for a Base64 media.payload, decode the Base64 in your test and inspect the underlying payload. When a protocol uses binary WebSocket frames, do not wrap them in a JSON string unless that protocol explicitly requires it. Twilio’s format is a text JSON message containing a Base64 field; its error reference warns against sending raw binary frames for that protocol. Twilio error 31950 describes this class of malformed message.

A WAV file is a container. Its RIFF/WAVE header is not part of raw μ-law samples. Conversely, a body of raw bytes is not a valid WAV file just because it contains audio samples. Keep a file for evidence if useful, but strip or add headers only at the boundary whose documented format requires them. The same rule applies to MP3, Ogg, WebM, and other container formats: a codec name alone does not say whether the endpoint wants a file, a packet, or raw samples.

A worked conversion path

Consider a hypothetical bridge with a phone stream that declares μ-law, 8 kHz, mono; a model endpoint that requires signed 16-bit linear PCM at 24 kHz, mono; and phone playback that again requires μ-law, 8 kHz, mono. This example is a conversion plan, not a claim that every vendor uses those formats. Verify the specific endpoint documentation before applying it.

The inbound transform is: validate the provider envelope; Base64-decode the payload; verify that the payload contains raw samples rather than a container; decode μ-law to linear PCM; resample from 8 kHz to 24 kHz with a real resampling algorithm; ensure the required channel count and signed sample endianness; then encode or pack the body as the model’s input contract specifies. A sample-rate field should describe the resulting signal. Changing only the field from 8000 to 24000 would make the receiver consume the same samples at three times the rate. That changes duration and pitch rather than creating the missing samples.

The outbound path reverses the appropriate transformations: read model output according to the response’s declared encoding; convert channels deliberately; resample to 8 kHz if that is what the phone stream requires; encode as the correct G.711 law; Base64-encode the raw bytes; and place them in the provider’s documented JSON text message. Preserve one owner for each transformation. If both an adapter and an SDK resample, the result can be resampled twice. If neither does it, the label may be false.

For the 8 kHz mono μ-law profile, a 20 ms interval corresponds to 160 samples because 8,000 samples per second multiplied by 0.020 seconds equals 160. Since each encoded G.711 sample is one byte, the corresponding raw sample payload is 160 bytes before Base64 expansion. This is arithmetic from the stated profile, not a claim that all providers require 20 ms chunks. Twilio’s media messages allow audio payloads of varying sizes; use its protocol, not this illustrative interval, to decide legal message size. A 24 kHz PCM16 mono interval of the same duration contains 480 samples and 960 sample bytes, because PCM16 uses two bytes per sample. Again, that is a calculated fixture for testing, not a universal model requirement.

Do not assume that “resampling from 8 to 24 kHz” adds recovered detail. Upsampling creates a denser representation; it cannot recreate frequencies removed by a narrowband phone path. It may be required by a downstream API, but it does not turn a telephone signal into a wideband recording. Similarly, downsampling browser audio can satisfy a phone endpoint while discarding content. State the intended outcome: compatibility, not imaginary restoration of source information.

The unresolved field question

A LiveKit community thread is a useful small example of the question that product docs alone do not resolve: an engineer reported voice warping after mixing TTS with background audio when a mixer was fixed at 48 kHz and the TTS provider did not support that rate; the distortion appeared on resource-constrained cloud machines but not local development laptops. The thread is a single reported incident, not a prevalence study, and it does not establish a universal cause. It does show why a team should test the deployed route and its mixer instead of assuming that a successful laptop demo proves the cloud path. Read the reported sample-rate-mixer issue.

The practical answer to “Why does my voice sound warped even though I set the sample rate?” is to inspect the boundary, not just the configuration. Check the number of decoded samples per timestamp interval, the sample format, the codec law, channel order, and whether any component is silently mixing or resampling. Compare the exact same deterministic fixture before and after each transform. If the waveform is already changed at an earlier stage, adjusting the final playback metadata hides the fault rather than correcting it.

User reports are valuable for discovery, but they are not interchangeable with controlled tests. The proper follow-up to a community report is a reproducible fixture, recorded versions, a trace of each transform, and a result under the same resource conditions. The article’s suite below makes that follow-up concrete.

Reusable asset: a 12-case compatibility suite

Run these cases in a staging environment with a synthetic signal and with one consented, non-sensitive spoken fixture. Use the same fixture at each observable checkpoint. Record the service version, adapter commit, provider setting, model setting, browser, operating system, and whether the test ran locally or in the target cloud environment. The date of this proposed suite is 25 October 2026. Its sample size is twelve designed scenarios; they are not twelve customer calls, twelve independent users, or an empirical estimate of defect frequency. Exclude real customer recordings unless separate permissions, retention controls, and access rules permit them. The suite does not evaluate transcription accuracy, accents, emotion, latency SLAs, or voice naturalness.

Case	Injected condition	Expected observation	Gate
1. Declared baseline	Correct codec, rate, channels, envelope	Metadata and decoded bytes match the route manifest	Pass only when every boundary value agrees
2. Rate relabel	Keep 8 kHz samples but label as 24 kHz	Validator detects manifest mismatch; no silent retagging	Reject before model send
3. Real resample	Decode then resample 8 kHz to the model’s required rate	Sample count changes according to duration; duration remains stable within chosen tolerance	Pass only with explicit resampler and measured duration
4. Law swap	Send A-law bytes to a μ-law decoder, or the reverse	Codec declaration mismatch is caught before listening review	Reject; do not infer law from random payload bytes
5. Channel mismatch	Supply stereo to a mono-only boundary	Channel count is rejected or a documented downmix is observed	No silent drop of one channel
6. Header leak	Prefix raw streaming payload with a WAV header	Header bytes are recognized in fixture or provider reports malformed playback	Reject raw-stream payload; strip at the correct boundary
7. Envelope type	Send raw audio bytes where text JSON is required	Protocol validator flags binary frame / wrong message shape	Reject before opening production route
8. Base64 corruption	Alter padding or one encoded character	Decode or integrity check fails; no substitute silence	Fail closed with a traceable error
9. Chunk sequencing	Duplicate, skip, or reorder a chunk identifier	Sequence anomaly is visible in trace	Do not concatenate as if continuous without an explicit recovery rule
10. Timestamp discontinuity	Introduce a timestamp jump or reset	Gap is recorded; duration calculation does not fabricate contiguous audio	Flag or apply documented gap handling
11. Restart boundary	Start a new stream with different metadata	Per-stream contract is rebuilt from the new start event	Never reuse stale metadata across calls
12. Cloud parity	Run the same deterministic fixture on local and target cloud worker	Compare contract, transform logs, and decoded checkpoints	Release only if target deployment passes independently

Cases 2–6 catch representation defects; cases 7–11 catch protocol defects; case 12 catches environment differences. These groupings are a design aid, not evidence that one category is more common. The baseline case must run first and again after a change to the codec library, media gateway, model API, browser stack, or adapter. A failed case should keep its input fixture, expected result, observed metadata, transform log, and exact error. Do not store raw customer speech in a general CI artifact.

What the suite can and cannot prove

The suite can prove that a declared manifest is consistent with observable metadata and with a set of known test vectors. It can prove that a particular code path rejects an incorrect rate label, a mismatched codec declaration, or an unexpected envelope. It can reveal that a transform changes duration, channel count, or sample count in a way the team did not intend. It can compare local and cloud traces for the same fixture.

The suite cannot prove that all phone carriers, browsers, headsets, languages, accents, microphones, packet-loss patterns, or model versions will behave identically. It cannot establish a user-perceived quality score without a defined listening method and representative participants. It cannot show that speech recognition is accurate, that a voice agent handles every interruption, or that business workflows are correct. Those need separate test plans. It cannot infer the codec from Base64 text or from a few byte values: companded audio has no reliable file header in the raw stream, and payload patterns alone are not a safe substitute for provider metadata.

A minimal executable manifest validator

The following Node.js example validates the declared profile and an inbound Twilio-shaped message envelope. It does not decode μ-law, resample, authenticate a WebSocket connection, verify a signature, or judge audio quality. Use a tested audio library and the provider’s current security guidance for those steps. The goal is to fail closed when the envelope contradicts the profile, before a model or playback service receives the bytes.

// node audio-contract-check.js <json-message>
// Example input: JSON string for a Twilio Media Streams start or media event.
const fs = require('node:fs');

const PROFILE = Object.freeze({
  provider: 'twilio-media-streams',
  encoding: 'audio/x-mulaw',
  sampleRate: 8000,
  channels: 1,
  transportMessage: 'text-json',
  payloadEncoding: 'base64-raw-audio-no-file-header',
});

function validateStart(message, profile = PROFILE) {
  const format = message?.start?.mediaFormat;
  const errors = [];
  if (message?.event !== 'start') errors.push('expected start event');
  if (format?.encoding !== profile.encoding) errors.push('encoding mismatch');
  if (format?.sampleRate !== profile.sampleRate) errors.push('sampleRate mismatch');
  if (format?.channels !== profile.channels) errors.push('channels mismatch');
  if (!message?.start?.streamSid) errors.push('missing streamSid');
  return { ok: errors.length === 0, errors };
}

function validateMedia(message, profile = PROFILE) {
  const errors = [];
  if (message?.event !== 'media') errors.push('expected media event');
  if (typeof message?.streamSid !== 'string' || !message.streamSid) errors.push('missing streamSid');
  if (typeof message?.media?.payload !== 'string') errors.push('payload must be a Base64 string');
  if (typeof message?.media?.payload === 'string') {
    const b64 = message.media.payload;
    if (b64.length % 4 !== 0 || !/^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$/.test(b64)) {
      errors.push('payload is not syntactically valid Base64');
    } else {
      const bytes = Buffer.from(b64, 'base64');
      if (bytes.length === 0) errors.push('empty audio payload');
      // This is a diagnostic only; byte values cannot identify μ-law vs A-law.
      if (bytes.subarray(0, 4).toString('ascii') === 'RIFF') errors.push('WAV header found in raw payload');
    }
  }
  return { ok: errors.length === 0, errors };
}

if (require.main === module) {
  const raw = process.argv[2] ? process.argv[2] : fs.readFileSync(0, 'utf8');
  let message;
  try { message = JSON.parse(raw); }
  catch { console.error(JSON.stringify({ ok: false, errors: ['invalid JSON'] })); process.exit(2); }
  const result = message.event === 'start' ? validateStart(message) : validateMedia(message);
  console.log(JSON.stringify(result));
  if (!result.ok) process.exitCode = 1;
}

module.exports = { PROFILE, validateStart, validateMedia };

This validator is intentionally narrow. The RIFF check catches a common WAV prefix, not every possible container. A correct Base64 string can still contain wrong audio. A passing message can still use the wrong codec law, rate, endianness, channels, sample order, or model contract if those values are not present in the message. Keep the manifest separate and compare it at each boundary. In production, use the SDK’s schema or generated message types where available; use the validator as a guardrail and test harness, not as a substitute for provider protocol validation.

Add deterministic fixtures

Do not use a customer call as the first test of a conversion. Generate or retain synthetic fixtures with known metadata: a one-second sine wave for duration and pitch checks, a silence segment for encoder/decoder behavior, a short impulse for truncation and filter-tail checks, and a clipped or low-amplitude waveform for conversion boundaries. A fixture should have a manifest that states its original rate, channel count, sample format, codec, expected decoded duration, and expected transformation path. When you change one field, write an explicit expected failure. Do not use the word “lossless” for a lossy codec conversion.

For speech, use a separately authorized and stable phrase that contains a beginning consonant, a vowel, and an ending consonant. The phrase is not a recognition benchmark; it is a listening aid for clicks, clipping, missing first frames, channel cancellation, and gross rate errors. Keep its text, speaker permission, source rate, and retention period attached to the fixture. If a human reviewer listens, use a fixed playback setup and blind the variant labels where practical. Report the panel size and protocol if you report subjective scores. This article reports no listening scores because no such panel was conducted.

How to localize a bad result

When a call sounds wrong, capture a checkpoint before and after each transformation, not just the final recording. At each point record codec, rate, channels, sample format, number of samples, byte length, timestamp range, stream ID, and the code version. Keep secrets and caller identifiers out of the ordinary log. An opaque per-test ID is enough to connect stages. If the provider makes a raw payload unavailable, record that observability limitation and test its edge behavior with the documented error response.

Start at the first point where the signal becomes wrong. If the bytes entering the resampler are already inconsistent with their metadata, changing the resampler is the wrong fix. If pre-resample duration is correct and post-resample duration is not, inspect the conversion ratio and state handling. If decoded PCM is correct but encoded μ-law playback is wrong, inspect the encoder law, output sample rate, and final envelope. If the file sounds good after export but the live stream does not, compare the live payload against the export: a recorder may automatically wrap, normalize, or transcode the signal.

Distinguish loss from corruption. A narrowband phone stream can sound less full than a browser track while remaining correctly encoded. That is an expected difference in channel capability, not evidence of a broken adapter. Repeated conversions can degrade quality even when each conversion is technically valid. A packet gap can create a click without a codec mismatch. A background mixer can expose a fixed-rate assumption that the speech path alone did not reveal, as the reported LiveKit issue illustrates. Preserve these hypotheses separately until a trace discriminates between them.

Do not “fix” every defect by increasing the model’s sample rate. A model endpoint’s format is a contract, not a quality dial. Do not “fix” a pitch shift by adjusting playback speed unless the intended sample clock itself is wrong and the change is acceptable. Do not remove the WAV header from an actual WAV-file API; the no-header rule applies when an endpoint asks for raw streaming media. Read the specific provider contract at the boundary under test.

Browser and phone are separate profiles

The browser profile should be derived from negotiated WebRTC data, not from the browser’s codec capability list. MDN explains that codecs must be mutually understood and that browsers may support more than the minimum set. The WebRTC codec guide describes Opus and G.711 in WebRTC, but a particular session can negotiate a different available choice. Capture the negotiated profile at run time and preserve the fallback behavior.

The phone profile should be derived from the particular media-stream or SIP contract. Twilio documents μ-law 8 kHz for Media Streams. SignalWire documents additional stream choices, including linear PCM at other rates and PCMA/PCMU. These examples are intentionally side by side: they prove that the adapter must honor a provider-specific contract; they do not prove every account has every option enabled. Verify region, account configuration, trunk negotiation, and API version against the current provider documentation before changing production settings.

For a dual-channel agent, define an adapter between profiles. A useful design is to keep a canonical internal representation only if it makes every conversion explicit and testable. “Canonical internal format” is a local engineering choice; it is not a claim that there is a single best codec for all paths. Select it based on the downstream model, memory and CPU budget, channel needs, acceptable quality, and the supported conversion library. Record where the canonical representation is created and where it is destroyed.

Run the same deterministic fixture through both routes. Then make real calls from the supported browser/device and telephone routes. Preserve the distinction between synthetic fixture tests and field tests. For field testing, record route and device classes without collecting more caller data than necessary. If a call-center team needs business context, pair technical failures with an operational outcome such as “route passed,” “agent fallback used,” or “caller had to repeat.” Do not translate one clean waveform into a claim that calls will resolve successfully.

The US Census Bureau’s American Community Survey overview describes a population survey, not a media-codec inventory. If an organization uses survey data to decide which populations to include in a field study, it must use the actual relevant ACS tables and methodology; the overview page alone does not justify a device or codec assumption. Inference: a representative participant panel and a compatibility matrix answer different questions. One cannot substitute for the other.

The Small Business Administration’s business-management guide is similarly general business guidance, not telephony engineering. Its appropriate role here is to remind an operator to treat this as a managed business change with defined outcomes and ownership. It cannot validate audio. Keep the technical release gate with the team that owns the adapter and the customer-service workflow.

Business case: measure the workflow, not the codec alone

A media path can pass every technical case and still produce a poor customer outcome. The voice agent can understand the stream and then route the request incorrectly. It can produce clear audio with stale information. A caller may be transferred to a queue that has no capacity. The reverse is also possible: a business process may be sound while one edge device sends malformed audio. Keep the technical acceptance suite separate from service outcome evaluation, then connect them through a shared test identifier and release version.

Bain’s service-center analysis discusses AI-enabled routing and service performance as process and data questions; it is a consulting analysis, not a benchmark for codec conversion or a promise of outcome for another company. Bain’s service-center analysis can inform the business discussion, but the field gates in this article are recommendations, not Bain’s findings. If you report a business impact, define the denominator, observation window, baseline, mix of call types, and comparison method. Avoid attaching a vendor’s broad case-study figure to this adapter’s effect.

At minimum, report these independent measures: proportion of test routes that pass the media contract; count and class of malformed frames; proportion of test calls that require human recovery; repeat request rate for the tested task; and caller-observable outcome. Label synthetic-suite results separately from operational call data. If you are not running a controlled comparison, call the result an observation, not a causal impact. If you have no permission to retain call audio, measure metadata and outcomes without storing speech.

The contract also affects ownership. A provider can document a correct message format, but your team still chooses the resampler, threading model, buffer policy, logging and rollback. A model provider can document its accepted input, but it cannot prove that an intervening gateway delivered that input. A systems integrator may own the adapter while the service owner owns the fallback. Put those responsibilities in a named deployment record before release. A mismatch with no named owner is not a “minor integration issue”; it is a missing control.

A practical acceptance workflow

1. Inventory endpoints. Name the exact phone provider, SIP trunk or browser route; the speech model and version; the adapter; the recording service; and the target deployment environment. Do not say “all browsers” or “all phone calls” unless the scope really covers them.
2. Read each contract. Capture the current provider page, model input/output requirements, and WebRTC negotiation expectations. Note when you checked them. Product defaults can change, and an account may have feature flags that the public docs do not expose.
3. Declare the boundary manifest. For every edge, list codec, sample rate, channel count, sample format, framing, transport message type, header policy, timestamp origin, and conversion owner. Mark “unknown” rather than inventing a value.
4. Create deterministic fixtures. Make the test media with known metadata. Store no customer speech in the fixture unless permission and retention controls are explicit. Keep the manifest and expected duration with the fixture.
5. Instrument transforms. Log before/after metadata at the decoder, mixer, resampler, encoder and transport serializer. Use a non-identifying test ID. Record errors but never log API keys, signatures, account secrets, or raw payloads by default.
6. Run the 12 cases. Fail closed on inconsistent metadata, malformed Base64, wrong frame type, stale stream metadata, or absent cloud parity. Attach the evidence for each failed case and do not silently skip it.
7. Make real route calls. Test from supported phones and browsers, network profiles, and target cloud workers. Confirm a narrowband result is an expected limitation rather than a broken conversion. Include an explicit safe fallback.
8. Review a release packet. Include manifest version, test run ID, failed/excluded cases, logs, versions, rollback path, owner for every transform, and the service outcome gate. A green unit test is not the same as a production call passing.
9. Canary and monitor. Enable only a bounded route or traffic slice that you can observe and reverse. Track provider protocol errors and caller recovery without turning logs into a voice-recording store.
10. Re-test after change. Repeat the suite when a provider setting, SDK, codec library, model API, browser policy, resampler, mixer, or deployment region changes. A version number in a manifest makes the scope auditable.

Mermaid view of the boundary logic:

flowchart LR
  P[Phone or browser source] --> M[Read negotiated metadata]
  M --> V{Matches route manifest?}
  V -- no --> X[Reject and preserve safe fallback]
  V -- yes --> D[Decode with declared codec]
  D --> R[Explicit resample / channel transform]
  R --> C{Matches model input contract?}
  C -- no --> X
  C -- yes --> A[Send to speech model]
  A --> O[Read declared model output]
  O --> T[Convert to target route format]
  T --> E{Envelope and payload valid?}
  E -- no --> X
  E -- yes --> U[Playback and record trace metadata]

Failure modes worth naming in the release review

Relabeling instead of resampling. The declared sample rate changes while the decoded sample count does not. Reject it. Compare duration from sample count and clock, not only the JSON metadata.

Wrong G.711 law. Both μ-law and A-law can look like anonymous bytes. Decode according to the negotiated or provider-declared codec. Do not choose one by guessing from a few values. If the route can use either, store the actual selection with the call/session metadata.

Double conversion. A gateway converts 48 kHz to 24 kHz and an application converts the same stream again because it did not learn the gateway had already acted. Name one conversion owner and capture both sides of that boundary.

Header contamination. A WAV header becomes the first “samples” of a raw stream. Inspect the raw bytes and payload contract. Do not strip file headers from interfaces that actually require a file.

Wrong frame type. A protocol expects text JSON, but the adapter sends binary audio. Audio bytes can be correct while the transport message is invalid. Validate envelope and frame type independently of decoding.

Channel collapse. Stereo is treated as mono, the wrong channel is selected, or channels are averaged with phase cancellation. Test known left/right fixtures, declare the downmix, and retain channel labels until that transformation is explicit.

Timestamp assumptions. Packet sequence numbers, presentation timestamps and sample clocks are not synonyms. Record units and origin. A timestamp jump may reflect a gap, restart, clock reset, or normal provider convention; do not fill it with fake contiguous audio without a recovery rule.

Cloud-only distortion. A local laptop has CPU headroom that the deployed worker does not. The reported LiveKit mixer example describes just such a difference. Test under the actual resource limits, with the same stream and library versions. A green local fixture does not waive cloud parity.

Stale profile after reconnect. A restarted stream can have new identifiers or media metadata. Reset per-stream adapter state at the start event. Do not inherit the previous call’s format or chunk counter.

Recording creates false confidence. A recording tool may normalize, wrap, transcode or resample. Compare raw points in the stream path with the exported file. Mark every recording with the point at which it was captured and its post-processing steps.

When this recommendation fails

This protocol is not a codec selection guide for music, broadcast, archival mastering, or high-fidelity studio recording. It is not a substitute for a provider’s current technical reference, a penetration test, load test, privacy review, model evaluation, or accessibility assessment. It does not say that every phone route must be 8 kHz μ-law. It does not say that WebRTC always uses 48 kHz Opus; negotiated codec, browser, endpoint and product choices matter. It does not mean every distortion report is a sample-rate defect.

The twelve cases are designed to expose a specific set of contract and transport mistakes. A production system still needs realistic packet loss, jitter, concurrent calls, codec negotiation, device/browser coverage, consented listening, language coverage, and service recovery tests. If call volume or risk requires statistical assurance, define a sampling plan and confidence bounds. The suite here has no statistical power calculation because it is a deterministic pre-release harness, not a representative field sample.

The ACS overview, SBA guide, and Bain analysis are included for narrow context: the first is a population-survey resource, the second a business-management resource, and the third a service-center consulting analysis. None of them specifies codec bytes or validates this implementation. The FCC’s older report describes how voice services bridge analog signals and IP through codecs, but its date and regulatory scope mean it should not be used as a current provider configuration guide. The FCC report is historical context only. The operational codec facts in this article come from the product and protocol documentation cited near those claims.

No relevant, caption-verifiable vendor video was surfaced in the focused search used for this article. A video walkthrough can help orient a team, but without a transcript and a versioned specification it should not override the protocol documentation or packet evidence. This is a research limitation, not evidence that no such video exists.

Decision table for buyers and engineering owners

Observed condition	Decision	Evidence needed before release
Product names a codec but omits sample rate or channels	Hold integration	Complete boundary manifest and runtime metadata
Rate field changes but sample count and duration do not reflect a real resample	Reject path	Before/after fixture trace and transform owner
Provider says raw audio but adapter includes a file container	Reject path	Serialized message bytes and protocol reference
Browser passes but phone path fails	Scope release to the passing route or fix adapter	Independent trace for each route; no “one demo proves all” exception
Local works but cloud worker distorts	Hold production rollout	Same-fixture cloud parity under deployment resource limits
A-law/μ-law is selected by guesswork	Hold release	Negotiated or declared codec metadata and decoder configuration
All 12 contract cases pass but task outcomes are unknown	Permit only technical integration test	Separate service workflow pilot and caller-recovery gate
Technical case fails but fallback is safe and observable	Limited canary may continue only if risk owner approves	Documented failure response, exposure bound, and rollback owner

Release checklist

• [ ] Every source and destination has a named format contract.
• [ ] Codec, sample rate, channels, sample representation, framing, and transport envelope are separate fields.
• [ ] A declared profile is compared with observed runtime metadata.
• [ ] Each actual resampling or codec conversion has one named owner and a before/after trace.
• [ ] The byte stream contains the expected raw payload or the expected container, never an accidental hybrid.
• [ ] Text-versus-binary framing matches the specific provider’s protocol.
• [ ] The G.711 law is explicit wherever G.711 is used.
• [ ] Browser negotiation is captured rather than inferred from browser support tables.
• [ ] Each phone, browser, cloud worker, and reconnect route has an independent result.
• [ ] The fixture suite is synthetic or properly authorized; raw calls are not stored by default.
• [ ] Technical compatibility results are not presented as speech accuracy or business impact.
• [ ] Community reports lead to a reproducible case, not a universal conclusion.
• [ ] Failed cases have an owner, safe fallback, and rollback condition.
• [ ] The release packet states date, versions, sample size, exclusions, and limitations.

A safe next step

If the team cannot answer “what exact bytes arrive at the model?” and “what exact bytes leave the playback adapter?” today, do not widen the rollout yet. Start with one provider and one route. Freeze a synthetic fixture, write the boundary manifest, run the twelve cases, and capture one trace from the actual target environment. Then add the second route and compare. This makes it possible to tell whether a defect came from conversion, framing, channel mixing, or a route-specific configuration instead of debating whether the model itself “sounds different.”

If a technical owner cannot instrument a boundary because the vendor hides it, that is not an invitation to guess. Record the hidden boundary as a dependency, test its documented inputs and outputs from both sides, and require an explicit failure response. If the outcome still cannot be observed, limit deployment to a reversible canary or choose an integration that exposes the information the operator needs.

The overall business decision should remain proportional. A low-risk, internal prototype can tolerate a documented unknown with a human operator and no consequential action. A public receptionist handling appointments, payments, safety issues, or identity-sensitive requests needs stronger verification and a reliable human fallback. This is not because higher sample rates make it safe; it is because the cost of a wrong or unintelligible interaction changes with the task. Keep audio correctness and workflow authorization as separate release gates.

For a broader picture of when phone automation is appropriate, compare the workflow and its fallback against the voice automation overview; treat that page as product context, not independent evidence for the codec contract. The final call should still be made from your own tested route, with the format manifest and trace packet attached to the release record.

Bottom line

The safe default is not “trust the demo” and not “force every component to the same rate.” It is to preserve truthful metadata, convert only at declared boundaries, and test the route’s actual protocol envelope before a caller depends on it. Use authoritative product docs for each boundary, an independently useful fixture suite for the transformations, and a separate operational pilot for customer outcomes.

Treat every claim according to its evidence: provider documentation states that provider’s format; a protocol standard states supported codec behavior; a community thread supplies a scoped troubleshooting lead; and a consulting analysis provides business context. None can replace the other. This contract-first approach is useful precisely because it shows what you know, what you inferred, and what remains unverified.