WebRTC vs WebSocket vs SIP: voice AI transport guide

TL;DR: Use WebRTC when the browser needs a real-time media session, WebSocket audio when your application deliberately owns framing and playback, and SIP when you need telephony session control. Draw the media boundary before choosing the model, then test connection setup, audible playback, interruptions, recovery, and shutdown separately.

A transport choice determines which failures your team must debug at three in the morning. It decides who handles packet timing, how an interrupted response is discarded, and whether a successful connection means a caller can hear anything.

These protocols occupy different layers. RFC 6455 defines a framed bidirectional protocol over TCP; RFC 3261 defines SIP session signaling; WebRTC combines browser APIs with a specified real-time protocol stack.

As of November 9, 2026, no matched transport benchmark accompanies this guide. The comparison below describes standards and engineering responsibilities, while the proposed workload tells you how to measure your own deployment using the speech-to-playback latency guide.

Contents

1. Choose the boundary first
2. Compare transport responsibilities
3. Design the WebRTC path
4. Design the WebSocket audio path
5. Design the SIP path
6. Preserve state across boundaries
7. Run a matched transport evaluation
8. Operate and secure each path
9. Frequently asked questions
10. Choose with a failure budget

Choose the boundary first

A voice transport is a contract about media ownership. Start by naming the endpoint your application controls: a browser tab, a custom microphone client, a carrier trunk, or an existing phone system.

A browser appointment assistant usually benefits from WebRTC because the browser already implements a media stack. A headless service sending known audio frames to a speech service may fit a WebSocket stream, while a phone call into a contact center requires telephone routing that neither a browser peer connection nor an arbitrary socket supplies by itself.

Several protocols can appear inside one call. A SIP trunk can terminate at a gateway that feeds audio into a WebSocket service, and a browser can use HTTPS for authentication before negotiating WebRTC media.

Do not label that architecture with one protocol and stop documenting. Each conversion creates another queue, clock relationship, security boundary, and possible disconnect sequence.

Write a path in plain language before drawing boxes. For example, a hypothetical application captures microphone audio in the browser, sends media to a regional gateway, calls a speech model from that gateway, then returns synthesized audio through the same browser session.

That sentence exposes the actual decisions. You need to establish who owns capture permissions, whether the gateway terminates encryption, how audio reaches the model, and which component can prove that response audio reached the output device.

A second hypothetical application begins with a telephone caller and ends with a carrier media gateway. The caller's handset behavior, the public telephone network, and carrier processing become part of the experience even when your own model service remains unchanged.

This is why a browser demo and a telephone production call need separate evidence. Compare task success using the outcome metric contract, then attribute transport-specific differences with traces rather than treating every delay as model latency.

Separate control, media, and business state

Control messages establish or modify a session. Media carries the sound, while business state records facts such as a confirmed booking or a completed handoff.

Keep these responsibilities explicit even when one provider wraps them in a convenient SDK. A WebSocket connection opening is a control-plane observation; receiving audio bytes is a media observation; an appointment appearing in the scheduling system is business evidence.

Three successful observations do not imply each other. A connection can stay open while no microphone samples are captured, and a caller can hear a fluent confirmation even when the downstream write failed.

The architectural acceptance criterion should join those observations without collapsing them. A successful test establishes an authenticated session, verifies two-way audible media, completes an authorized task, and confirms that all live media work stops when the session ends.

For tool writes, use the safeguards in enforced voice workflows. Transport reliability cannot supply missing authorization or repair an incorrect business action.

Compare transport responsibilities

The table uses ✓ for a capability supplied by the named standard or browser API at the stated layer. A ✗ means your application or another system must provide it; it does not mean the protocol cannot participate in a system with that feature.

The WebRTC transport specification requires secure RTP media and defines its connection stack, while a WebSocket audio service still needs its own agreement about encoding, sample rate, and message meaning. SIP establishes sessions that can carry media through separately negotiated paths.

Choose on these ownership differences before comparing vendor headline latency. Any credible performance claim must name the endpoint, packet route, codec, queue behavior, concurrency, and measurement boundary.

Calculate payload before comparing volume

For uncompressed mono PCM, payload bytes per second equal sample rate multiplied by bytes per sample. A hypothetical 16 kHz, signed 16-bit mono stream produces 32,000 payload bytes per second before framing or network overhead.

If that stream uses 20 millisecond application chunks, each chunk holds 320 samples and 640 payload bytes. Those values come from arithmetic, not a measured provider result or a recommended universal chunk size.

Stereo doubles the sample count at the same rate. Base64 encoding adds representation overhead, so compare binary and textual message paths using the actual provider contract rather than estimating costs from raw PCM alone.

Compressed audio changes the calculation. You must inspect the negotiated codec and encoding settings, then measure bytes on the relevant leg because the browser-to-gateway path can differ from the gateway-to-model path.

Neither lower payload volume nor a smaller frame proves lower conversational latency. Smaller chunks can add scheduling overhead, while larger chunks delay availability and accumulate more stale speech during interruptions.

Validate a media-format assumption

Make the payload arithmetic executable before debugging a live stream. The following vendor-neutral self-check uses a synthetic mono PCM format and checks frame alignment; it sends no audio and does not specify a managed service API.

sample_rate = 16_000
channels = 1
bytes_per_sample = 2
chunk_ms = 20
samples_per_chunk, remainder = divmod(sample_rate * chunk_ms, 1000)
assert remainder == 0
bytes_per_second = sample_rate * channels * bytes_per_sample
chunk_bytes = samples_per_chunk * channels * bytes_per_sample
assert chunk_bytes == 640
assert bytes_per_second == 32_000
assert 64_000 / bytes_per_second == 2
assert chunk_bytes % (channels * bytes_per_sample) == 0

Save the snippet and run it with Python 3. It establishes the stated format calculation, while a real decoder and an audible fixture are still needed to verify actual input and output handling.

A common diagnostic mistake is checking only that a frame contains an even number of bytes. That detects one class of truncation for this format, yet it cannot detect swapped byte order, an incorrect sample-rate declaration, or audio assigned to the wrong response generation.

Use a synthetic fixture with a known duration and a clear beginning and ending. Compare the number of accepted samples with the expected duration, then listen through the actual playback path rather than inspecting the source file alone.

Preserve that fixture when changing a gateway or client library. If its duration changes after a migration, inspect conversion and scheduling before adjusting recognition or turn-detection settings.

For an intermittent problem, collect queue age at a fixed observation interval and correlate it with application scheduling stalls. A flat byte queue can still hide delayed playback if the client has already moved the audio into another buffer that your current metric never observes.

Keep the fixture and timing observations free of real caller content. A reusable synthetic diagnostic gives another engineer enough evidence to reproduce the boundary error without needing access to a private recording or the original caller's identity.

Design the WebRTC path

Use a peer connection for real-time browser media and keep application authorization on your server. The W3C WebRTC recommendation defines browser interfaces for connection establishment and media handling; your application still decides who may start which agent session.

A practical setup sequence begins with a user gesture and microphone permission. Your application then obtains a scoped session authorization, exchanges the required signaling information through its chosen signaling channel, and waits for a usable media path.

Signaling is application-specific. A WebRTC application can use HTTP or a socket to exchange descriptions without sending its audio through that same channel.

sequenceDiagram
    participant B as Browser
    participant A as App server
    participant G as Media gateway
    participant V as Voice service
    B->>A: Request authorized session
    A-->>B: Return scoped setup data
    B->>G: Exchange session descriptions
    B->>G: Establish secure media path
    B->>G: Send microphone media
    G->>V: Forward accepted audio
    V-->>G: Return response audio
    G-->>B: Deliver media for playback
    B->>A: Report session outcome

This is a vendor-neutral responsibility diagram, not a 60db Agent API specification. Implement the exchange using the selected service's current documented contract and never place a persistent service credential in the browser bundle.

Treat ICE as a route selection process

ICE gathers and tests possible paths between endpoints. RFC 8445 specifies candidate-based connectivity checks, which explains why a successful signaling exchange can precede a failed media path.

A direct route and a relay route can produce different operational results. Record the selected candidate pair and the relevant connection events using the browser's available statistics, while treating network addresses as sensitive operational data.

A relay is not automatically a failure. Some networks require one, and your production success criteria should include permitted relay use instead of optimizing only for a favorable development network.

Test restrictive corporate networks and ordinary mobile networks separately. If the only acceptance test runs over an office network with broad UDP access, it tells you little about a caller behind a different firewall policy.

Avoid retry loops that repeatedly request new sessions while the old session is still recovering. They can leave several microphone tracks or server sessions active and make later observations look like echo, duplicate speech, or unexplained billing.

Observe the endpoint without collecting content

MDN documents RTCPeerConnection.getStats() as the browser API for retrieving connection statistics. Use available RTP and candidate-pair reports to investigate packet movement, loss, and route behavior, checking actual field support in your target browsers.

Take deltas for cumulative counters and preserve units. A counter increase says packets moved during the interval; it does not establish that a human heard useful words.

You also need application events for capture started, remote track attached, playback attempted, and playback permitted. Browser autoplay policy or a muted output element can prevent audible sound after a technically healthy media negotiation.

Use a consented loopback or a known test phrase when checking audibility. Do not turn routine diagnostics into full recordings of every production call merely because recordings are easier to inspect.

A media trace becomes more useful when it shares a call identifier with the complete call trace. Keep that identifier out of public screenshots and aggregate it before sharing a report.

Handle browser lifecycle explicitly

Tabs become hidden, devices change, and a caller can withdraw microphone access. Decide what each event means for your application before promising continuous voice interaction.

An output-device switch may require the caller to confirm that sound is audible again. A lost input device should produce a visible, accessible state that explains the problem instead of allowing the assistant to continue waiting silently.

Stop microphone tracks when the user ends the interaction. Closing the peer connection and ending local capture are related actions that deserve separate assertions in the test suite.

Use the shutdown semantics guide to distinguish session cleanup from authorized post-call processing. A record summarizer may continue after hangup, while microphone capture and live response playback must obey the session's stop boundary.

Design the WebSocket audio path

WebSocket audio requires an application-level media contract. The socket provides messages; your code and the service define what those messages mean and how their contents become timed sound.

Define the encoding, sample rate, channel count, byte order, chunk duration, timestamp interpretation, and stream lifecycle. For compressed data, specify whether chunks form complete decodable frames or fragments of a longer stream.

An audio contract must also describe outbound behavior. The client needs to know whether response chunks can be played immediately, whether they belong to a particular response generation, and how the service signals completion or cancellation.

sequenceDiagram
    participant C as Audio client
    participant S as Stream endpoint
    participant M as Speech processing
    C->>S: Authenticate and agree media format
    C->>S: Send framed audio chunks
    S->>M: Forward accepted input
    M-->>S: Return generated output
    S-->>C: Send response generation chunks
    C->>C: Queue and play current generation
    C->>S: Cancel interrupted response
    C->>C: Discard queued stale audio

These labels describe required responsibilities, not invented wire events. Use the service's documented field names and cancellation behavior when building an actual client.

Bound queues in units of time

The browser WebSocket API does not provide automatic application backpressure; MDN's WebSocket reference warns about memory and CPU problems when messages arrive faster than the application processes them. Track queue age as well as bytes.

A byte threshold has different audible meaning for different encodings. With the illustrative 32,000-byte-per-second PCM stream, 64,000 queued payload bytes represent two seconds of audio before adding decoding or playback delay.

That is an arithmetic example, not an acceptable queue target. Choose a queue limit from the interaction's delay budget and define what happens when the limit is exceeded.

For outgoing microphone media, silently retaining old chunks can turn a brief network stall into several seconds of stale caller speech. Depending on the service contract, the correct response may be to restart the stream or explicitly mark a discontinuity rather than replay everything.

For incoming response media, an interrupted generation should be invalidated immediately. Clearing a JavaScript array is insufficient if the same audio has already been scheduled into an output graph or native playback buffer.

The interruption-safe state machine supplies the generation boundary you need. Your application must coordinate the server cancellation with local playback invalidation and stale-message rejection.

Understand ordered transport under loss

TCP presents an ordered byte stream. If missing data prevents progress, later bytes are not exposed as though the earlier part never existed, which can increase delivery delay during packet loss.

This property is useful for many application messages, yet real-time audio has deadlines. Audio that arrives intact after its useful playback time can still damage the conversation.

Do not conclude that WebSocket audio always performs worse than WebRTC. Route length, server queues, codec processing, model behavior, and workload can dominate a particular deployment.

Measure under the network conditions you expect. An application designed for reliable local-network audio between controlled servers faces different conditions from a browser client crossing mobile networks while a caller walks between coverage areas.

Resume business state conservatively

A reconnect creates a new transport connection. It does not establish which previous audio was processed, heard, or acknowledged by the caller.

Define a resume contract before implementing automatic reconnect. The contract should describe session expiration, accepted input position if supported, response generation state, and whether an incomplete tool action can be queried safely.

If the service provides no resume guarantee, start a fresh media session and reconcile business state from durable records. Tell the caller what happened without repeating an action whose outcome remains uncertain.

The read-early, commit-once tool guide is useful here because transport retries and business retries must use separate rules. Retrying a socket connection is not authorization to repeat a booking request.

Design the SIP path

SIP handles session signaling between telephone-capable endpoints and infrastructure. Audio typically travels through a separately negotiated media path, so the SIP dialog and the media route need independent inspection.

A successful final response to an invitation does not prove two-way audio. The advertised media address can be unreachable, codecs can disagree, or a gateway can receive sound in only one direction.

sequenceDiagram
    participant P as Phone endpoint
    participant C as Carrier or PBX
    participant G as Voice gateway
    participant A as Agent service
    P->>C: Start telephone call
    C->>G: Send SIP invitation with media offer
    G-->>C: Accept with negotiated media
    C->>G: Send caller media
    G->>A: Forward converted audio
    A-->>G: Return generated audio
    G-->>C: Send response media
    C-->>P: Deliver telephone audio
    C->>G: End dialog

The diagram is intentionally explicit about the gateway. A telephone caller does not become a browser peer merely because the voice application uses WebRTC somewhere else in its infrastructure.

Follow both directions through conversion

Write down the negotiated codec and sample rate on every media leg. A carrier path can use one format while your speech provider expects another, and each conversion must preserve duration and channel interpretation.

RFC 3550 defines RTP sequence numbers and timestamps for real-time media transport. Those fields help explain packet ordering and media timing, although they cannot prove that the final speaker produced audible sound.

Look for reversed assumptions. A gateway that decodes incoming telephone audio correctly may still encode outgoing audio incorrectly, creating a one-way failure that a connection-level health check misses.

Use a known tone or consented spoken fixture in both directions and compare duration. A sample-rate mismatch can change pitch and playback speed even when every component reports valid bytes.

If the call connects but sound fails, follow the SIP audio troubleshooting sequence. Capture signaling and media facts narrowly, avoiding unnecessary disclosure of telephone numbers, network addresses, or authentication headers.

Check format, duration, and audible fixtures in each direction; a connection event cannot prove two-way media.

Plan transfers as additional sessions

A transfer can introduce another call leg, another participant, and different media routing. Specify whether the assistant remains present, which participant can hear the summary, and what event proves the destination answered.

Do not mark a transfer successful when only a request was accepted. A busy destination, unanswered leg, or failed bridge can leave the caller waiting after the application has already recorded success.

Use the warm handoff contract to preserve the caller's confirmed context and define fallback behavior. The transfer outcome belongs in business state, while its signaling and media events belong in the call trace.

Your telephone test should include destination busy, no answer, remote disconnect, and caller disconnect during transfer. Each case changes which resources must be closed and whether a fallback conversation remains possible.

Preserve telephony policy boundaries

Telephone deployments add operational and policy requirements that browser tests do not exercise. Number provisioning, calling permissions, caller identification, regional routes, and recording decisions depend on your provider and use case.

Verify them with the current service documentation and responsible policy owners. A transport architecture article cannot establish permission to call a person or record a conversation.

When evaluating 60db Agent, confirm the selected workspace's capabilities using the Agents documentation and BYO SIP contract separately. Public inbound availability is unconfirmed, so an outbound or browser test must not be presented as evidence that inbound calling is generally available.

Preserve state across boundaries

Use one logical session record with explicit transport attempts beneath it. A browser reconnection, SIP re-invitation, or replacement WebSocket connection should not silently create a second business interaction.

Give each attempt an identifier and retain its relationship to the session. Within the session, track response generations so late audio from a canceled response cannot become current merely because it arrived over a healthy replacement connection.

A useful state vocabulary distinguishes session authorized, media connecting, media ready, listening, responding, reconnecting, handing off, ending, and ended. Choose the states your application needs and define permitted transitions instead of copying a large generic framework.

The transport adapter should report observations. The application decides whether those observations permit a business transition, and the playback layer decides whether a chunk still belongs to the current response generation.

Reconnect the transport while retaining task identity and reconciling uncertain business actions.

Define interruption at the audible boundary

The caller experiences interruption as a change in audible behavior. A server acknowledgment of cancellation is useful evidence, yet it does not remove audio already buffered at a browser, gateway, or telephone device.

Record interruption detection time, cancellation request time, last audible response time, and whether stale speech resumes. Keep caller speech detection separate from a policy decision to interrupt because background speech and short acknowledgments need different treatment.

The VAD and turn detection guide explains that distinction. A transport migration can alter buffering enough to change interruption behavior even when turn detection settings remain unchanged.

Test an interruption while the agent is speaking a long response and while a tool is pending. The system should preserve confirmed caller facts, discard canceled assistant speech, and prevent delayed tool results from reviving the abandoned response.

Treat shutdown as a distributed action

A call ends in more than one place. The browser must stop tracks and playback, the gateway must close media work, and server tasks must follow their declared post-call policy.

A remote disconnect can arrive before a final outcome event. Build an idempotent finalization path that tolerates repeated notifications and delayed recording metadata without keeping live audio resources indefinitely.

Do not block media cleanup on analytics delivery. If an outcome export fails, a durable retry can preserve reporting while allowing the microphone and call leg to close promptly.

This separation also improves cost accounting. The cost-per-success guide can attribute media duration, retries, and post-call work without assuming that every component shares one billing boundary.

Run a matched transport evaluation

Compare transports using the same task and explicit endpoint measurements. A protocol comparison without workload control mostly measures different applications.

Start with a consented fixture set containing a short request, a longer request, an interruption, a thinking pause, a slow tool result, and a remote disconnect. Keep the spoken content and task assertions fixed when comparing supported paths.

Control model version, prompt, tool implementation, region, and concurrency where the platform allows it. Record any factor you cannot match, such as carrier routing or a provider-selected codec, so readers understand the limits of the comparison.

Measure setup time separately from steady-state response delay. A connection that takes longer to establish may still behave well once established, and a quick setup can hide growing queues during sustained interaction.

Use monotonic clocks for durations measured within one process. For cross-device timing, either use an externally observed audio method or document clock alignment and uncertainty rather than subtracting unrelated timestamps.

Publish a workload manifest

A small manifest should identify fixture version, task policy version, transport mode, client platform, region, concurrency, and network profile. Use opaque test identifiers so the manifest can be shared without caller information.

Declare which samples were cold starts, which used an established connection, and how failures were counted. If a call never produces sound, it belongs in the setup failure denominator rather than disappearing from the latency distribution.

Keep raw traces private and publish aggregates with enough context to interpret them. A median alone hides long stalls, so include tail behavior, failure counts, and the number of trials per condition.

The regression harness guide supplies the release structure. Add transport-specific assertions to that shared harness instead of maintaining independent test scripts with different definitions of success.

These are proposed criteria, not published benchmark results. A team must choose actual timing thresholds from its use case and then measure whether the implementation meets them.

Inspect what changes under load

A single successful call verifies one path at one moment. Concurrent sessions expose shared worker saturation, event-loop stalls, outbound connection limits, and growing synthesis queues.

Increase concurrency in controlled steps while preserving the workload mix. Observe queue age, CPU, memory, connection failures, and task success alongside latency.

Do not assume every transport shares the same bottleneck. Browser WebRTC may stress relay capacity, a socket service may accumulate application buffers, and a telephone gateway may hit carrier or trunk limits before the model service saturates.

Repeat the same tests after changes to codecs, gateways, deployment regions, or audio chunk sizes. These changes can alter the caller experience without any prompt modification, which is why transport configuration belongs in the versioned evaluation record.

Operate and secure each path

Authentication should authorize a narrow session and expire promptly. Keep durable provider credentials on trusted servers, validate session ownership, and enforce limits before creating expensive media resources.

Encryption needs a path-specific description. WebRTC media protection, TLS on a WebSocket connection, and encryption on a SIP signaling hop describe different links; none proves that audio remains encrypted after a gateway decrypts it for processing.

Map those decrypting components using the local versus managed data-boundary guide. Include recordings, transcripts, debug logs, and tool payloads because a secure media path can coexist with excessive content retention elsewhere.

Telemetry should reveal timing and state without exporting the conversation by default. Separate a protected diagnostic sample from routine metrics, and define retention for both before an incident encourages broad collection.

Connection encryption does not describe downstream processing, logs, recordings, or storage after decryption.

Make health checks reflect useful service

A listening port proves little about usable voice. Maintain separate health observations for application readiness, session establishment, and a synthetic two-way media check on supported test routes.

The synthetic route should use approved destinations and explicit test identities. It should never dial arbitrary real people or write production business records as a side effect of checking availability.

Drain existing calls during deployments when the platform supports it. Stop admitting new sessions before ending the process, allow bounded active work to finish, and record sessions that exceed the shutdown policy.

Avoid silently routing failed calls to an unapproved region or provider. A fallback changes data boundaries and possibly caller expectations, so it needs the same explicit configuration and evaluation as the primary path.

Keep multilingual evaluation transport-aware

Audio conversion can damage names, digits, and language switching differently. A transcript-only test misses caller-facing pronunciation and output pacing failures.

Run the multilingual task evaluation through the actual transport used by each audience. Keep language cohort results separate when codec or carrier routes differ.

If a task fails only over one path, inspect the captured audio boundary before changing the model prompt. A sample-rate or channel error can look like poor recognition, and prompt edits will only obscure the cause.

For a 60db Agent evaluation, use documented capabilities available to your workspace and ask for missing boundary details before a production decision. This guide makes no claim about private implementation, transport performance, residency, or local deployment.

Frequently asked questions

Is WebRTC always faster than WebSocket audio?

No universal ranking follows from the protocol name. WebRTC supplies a real-time media stack, while WebSocket behavior depends heavily on application buffering and network conditions; compare actual speech-to-playback delay, interruption behavior, and failures under a matched workload.

Does SIP carry the audio itself?

SIP establishes and manages sessions. Audio commonly travels over a separately negotiated RTP media path, so inspect the signaling dialog and both media directions independently when troubleshooting a call.

Can one voice application use all three?

Yes. A browser can use WebRTC to a gateway, the gateway can exchange model audio over WebSocket, and a telephone connection can use SIP signaling with another media leg; document every boundary rather than hiding them behind one product label.

Does WebRTC need a signaling server?

Peers need a way to exchange setup information, but the application chooses that signaling mechanism. It can use an existing authenticated application channel; the media path does not have to follow the same route as those signaling messages.

Does WebSocket define an audio format?

No. Your application and service must agree on encoding, sample rate, channels, framing, and lifecycle semantics, including how a response is completed or canceled.

What does a TURN relay change?

A relay changes the media route and introduces capacity and operating considerations. It can be necessary for connectivity on restrictive networks, so include permitted relay use in production tests instead of treating every relayed call as unsuccessful.

Can a connected call still have no sound?

Yes. Signaling can succeed while a media address is unreachable, capture has not started, playback is blocked, or audio conversion is wrong; a complete acceptance test observes audible media in both directions.

Should I send binary or base64 audio?

Use the documented service contract. Binary avoids base64 representation overhead where supported, but the full choice also depends on framing, decoding, client support, and whether your existing service accepts the selected encoding.

What is a good audio chunk size?

There is no universal value. Choose from the provider contract and your delay budget, then test scheduling overhead, queue age, interruption behavior, and CPU under realistic load before making the setting a production default.

Does reconnect mean the conversation resumes?

Only if the application and service define a resume contract. A new transport connection does not prove which audio was processed or heard, so reconcile business actions and avoid blindly replaying pending writes.

How should I compare browser and phone latency?

Keep the task and controllable model settings fixed, then publish the different endpoint and carrier conditions. Measure audible response at the caller boundary and report unmatched codecs or routes instead of presenting the result as a pure protocol benchmark.

Can I use WebRTC for server-side agents?

Yes, compatible server components can participate in WebRTC media sessions. Whether that is useful depends on the endpoint and gateway requirements; a controlled server-to-server stream may have a simpler documented transport available.

Does TLS make a socket architecture private?

TLS protects a connection between its endpoints. The receiving service can still process, log, retain, or forward the decrypted content, so privacy evaluation must include downstream processing and storage contracts.

What should stop when a caller interrupts?

The current response generation should stop producing audible output according to the application's policy. Coordinate server cancellation, local playback clearing, and stale-chunk rejection, then verify that delayed audio cannot resume.

Can codec conversion affect recognition?

Yes. Incorrect sample-rate or channel handling can alter the audio presented to recognition, while lossy conversion can change useful signal details; compare the actual boundary audio before attributing every recognition failure to the model.

Should transport failures count as task failures?

They belong in an explicit metric. Report setup failures and end-to-end task success alongside the conversational success rate so removing failed connections from the denominator cannot make the system appear healthier.

How do I test microphone cleanup?

End the session through each supported path and inspect capture tracks, playback, connection state, and server media work. Include remote hangup and setup failure, since cleanup that works only after the normal end button leaves important paths uncovered.

Can a transport retry duplicate a booking?

Yes, if reconnect logic replays business actions without reconciliation. Use durable action identifiers and the business system's documented deduplication or lookup behavior, keeping transport retry decisions separate from authorization to write.

Which 60db Agent surfaces should I benchmark?

Benchmark only the browser, streaming, or SIP surfaces currently documented and enabled for your workspace. Confirm prerequisites and supported directions; public inbound availability is unconfirmed and should not be inferred from a successful outbound test.

What should I build before a transport migration?

Build a matched regression workload with audible-media observations and durable task assertions. That gives you a baseline for setup, latency, interruption, recovery, and shutdown, allowing the migration to be judged on evidence rather than a more convincing demo.

Choose with a failure budget

Pick the boundary that fits the caller and assign every remaining responsibility. Browser media, custom audio streams, and telephone sessions have different operational owners even when they feed the same model.

Before committing to a transport, produce a route diagram, a media-format contract, a cancellation contract, and a small evaluation report. Those artifacts should explain what happens when setup fails, when a caller interrupts, when a connection drops after a write, and when one side hangs up first.

Start with a single supported path and prove two-way audio plus one real task in a controlled environment. Add the next path only when its endpoint requirement is real, then reuse the same task fixtures and outcome definitions to compare the experience.

For 60db Agent, make that first evaluation a documented workspace test. Confirm available transport surfaces, collect redacted timing and outcome evidence, and use the resulting failure record to choose your deployment boundary.