SIP connects but there is no audio

TL;DR: A successful SIP exchange establishes signaling state, while usable audio depends on negotiated media, reachable RTP paths, correct decoding, and application playback. Diagnose silent calls by following those boundaries in order and proving both media directions before changing prompts or speech models.

Your call shows connected. The agent never hears the caller, or the caller never hears the greeting, and retrying produces the same silence.

A connected status narrows the problem, but it does not clear the media path. SIP messages can traverse one route while audio packets use different addresses, ports, protocols, and firewall rules.

The fastest useful investigation establishes the last confirmed boundary. Connect the evidence to a complete call trace, then inspect signaling, SDP, packet flow, decoding, and application behavior without changing unrelated components between tests.

Reviewed November 9, 2026. The examples below use documentation-only addresses and synthetic observations; no customer packet capture, live call experiment, or measured fault prevalence is presented.

Table of contents

1. Separate signaling from media
2. Establish a bounded reproduction
3. Read the negotiated SDP
4. Prove the RTP path in both directions
5. Verify codec and audio interpretation
6. Inspect application and conversation boundaries
7. Qualify the 60db Agent SIP route
8. Turn the diagnosis into regression coverage
9. Frequently asked questions
10. Repair the last unproved boundary

Separate signaling from media

A successful SIP dialog is evidence about call control, not proof of intelligible bidirectional audio. Media has its own negotiation and transport path.

SIP's core specification, RFC 3261, defines session initiation and related signaling behavior. A normal answer exchange can complete while a firewall blocks the UDP media packets that the endpoints negotiated.

SDP describes the media session. RTP carries real-time media, and RTCP can provide related control and reception information; those roles are distinct even when a deployment routes them through the same physical host.

That separation gives you a diagnostic order. First confirm the intended dialog and media offer/answer, then prove packets arrive at the negotiated destination, then prove the payload becomes valid audio at the application boundary.

A voice agent adds more stages after media ingress. The runtime can receive and decode speech successfully while the endpointing policy never permits a response, or it can generate a greeting that the output path never transmits.

The transport comparison explains why a successful browser test does not qualify the SIP route. Browser and phone paths can share conversational logic while using different media negotiation, codecs, and network boundaries.

Classify the symptom precisely

Distinguish no audio in either direction, caller-to-agent only, agent-to-caller only, garbled audio, intermittent gaps, and delayed audio. Those descriptions correspond to different evidence and should not be collapsed into a generic call failure.

Ask whether the agent receives speech evidence and whether the caller hears any sound at all. A greeting heard correctly followed by silence after the caller speaks is different from a call that never produces a greeting.

Record whether the failure occurs before or after transfer, hold, re-invitation, or a period of inactivity. A path that works initially and fails after renegotiation points toward changed media state rather than an always-invalid codec configuration.

Keep those observations separate from conclusions. "No inbound RTP observed at the application host" is evidence; "carrier outage" is a hypothesis until the adjacent boundaries establish where the traffic disappeared.

Use a boundary matrix

A checkmark below indicates that evidence can establish the stated boundary when collected correctly. It does not imply a particular vendor supports the diagnostic or that passing one row proves the later rows.

An operator can use the matrix to stop a common detour: changing the prompt while the media destination is wrong. A language model cannot answer audio it never receives.

It also prevents the opposite mistake. Once input speech is decoded and response audio is sent, a silent remote endpoint needs output-path evidence rather than repeated speech-recognition tuning.

Establish a bounded reproduction

Use an authorized test number or controlled endpoint and a short synthetic script. Avoid real customer information, and ensure recording or packet capture is permitted before collecting media content.

Write down the route, direction, line configuration, time window, and relevant version identifiers. The goal is a reproduction that another engineer can follow without reconstructing private caller details.

Keep the call short and predictable. A known greeting followed by a known test phrase makes it easier to distinguish absent packets, digital silence, wrong decoding, and conversational policy failure.

A successful control call is useful only when it changes one relevant boundary. If the control uses a different carrier, region, codec, device, and application version, it demonstrates a working route but does little to isolate the failing one.

The regression harness guide provides a wider test structure. During diagnosis, use the smallest scenario that preserves the failure rather than running a full conversation suite after every configuration change.

Preserve evidence before restarting

A restart can clear a transient condition and erase the evidence needed to explain it. Capture the current negotiated media, bounded counters, and terminal events before changing the state, unless immediate recovery takes priority for an active incident.

Record what changed between attempts. If you alter NAT settings and codec preferences together, a passing retry leaves you unable to say which repair mattered or whether the other change introduced a hidden risk.

Use a short hypothesis log in the incident record. Each entry should state the suspected boundary, the observation that would support it, the test performed, and the result.

Do not turn that record into a permanent store of SIP credentials, full phone numbers, or media payloads. Keep sensitive diagnostic artifacts in the approved location with a retention limit and reference them through controlled identifiers.

Capture metadata before payloads

Start with signaling metadata, SDP fields, packet counts, source and destination tuples, and payload-type observations. These can explain many routing and negotiation defects without decoding speech.

Packet captures can still contain sensitive information even when the payload is encrypted. SIP headers, addresses, identifiers, and timing can reveal relationships, so treat a capture as controlled diagnostic material.

If payload inspection becomes necessary, use the synthetic test call and capture only the relevant interfaces and time window. Avoid broad host captures that collect unrelated traffic from other workloads.

The data-boundary guide applies to troubleshooting tools as well. Uploading a capture to an external analyzer changes where operational and potentially personal data is processed.

Use tools you actually have

A SIP ladder viewer, packet analyzer, media counters, and application logs are complementary. None is mandatory by brand, and installing another tool is unnecessary when the existing stack already exposes the required evidence.

Verify tool versions and supported decoding before trusting a visual label. An analyzer may infer a stream as RTP from heuristics or fail to decode a dynamic payload type without the relevant SDP.

Where managed infrastructure hides packet access, ask for the smallest missing evidence: negotiated media, direction-specific packet counts, decode errors, or a provider trace identifier. Do not fabricate a packet-level conclusion from a high-level connected status.

Read the negotiated SDP

SDP tells each side which media addresses, ports, formats, and directions were offered or accepted. Read the actual offer and answer from the failing dialog rather than the configuration file you expected to generate them.

The SDP specification, RFC 8866, defines the session-description fields. The offer/answer model in RFC 3264 explains how endpoints negotiate those descriptions.

Inspect the connection address and media line together. A syntactically valid offer can advertise an address unreachable from the other endpoint, especially when a private address escapes through a NAT boundary.

Also inspect direction attributes. A stream negotiated as inactive or receive-only can produce silence that looks like a network failure if the operator checks only the codec list.

Work through a synthetic media description

The following SDP fragment is illustrative. The address belongs to a documentation range, and the port is an example rather than a recommended firewall opening or provider configuration.

v=0
o=- 1 1 IN IP4 192.0.2.10
s=Controlled media test
c=IN IP4 192.0.2.10
t=0 0
m=audio 40000 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=sendrecv

This fragment offers two named audio formats and a bidirectional media direction. The actual answer determines the negotiated result, so reading only this offer cannot prove what the call used.

The fields are operationally connected. If packets go to another address or port, investigate translation or routing; if the payload uses a format absent from the negotiated answer, investigate negotiation or sender behavior.

Do not use the fragment as a complete production SIP setup. Real dialogs also depend on signaling, authentication, route policy, and any additional attributes required by the selected transport and endpoints.

Check session-level and media-level values

SDP can carry fields at different scopes. A media-level value can override a session-level value, so inspect the effective audio description rather than searching for the first address in the message.

Multiple media sections require deliberate matching. A rejected or inactive section should not be mistaken for the active audio stream, and a second call leg can negotiate a different destination from the original leg.

A zero media port has specific negotiation meaning and should not be interpreted as a real RTP destination. Treat it as a clue about the accepted media state, then inspect the surrounding offer/answer exchange.

Keep this review attached to the exact dialog and revision. A later re-invite can replace a previously valid media destination, so the initial SDP may no longer explain the failing interval.

Watch renegotiation boundaries

Hold, transfer, codec changes, and session refresh behavior can alter media state. Mark the last point where audio worked and compare the effective description before and after that point.

If audio disappears after a re-invite, verify that both ends applied the same new state. A gateway can keep sending to an old tuple while the application has already switched its receiver.

Do not repair this by pinning arbitrary ports or disabling all renegotiation without understanding the route's contract. A workaround can restore one scenario while breaking hold, transfer, or another supported carrier.

The warm handoff guide explains why transfer testing needs media-leg evidence. A successful transfer request does not prove the new participant receives the expected audio.

Compare the effective media state before and after hold, transfer, or re-invitation.

Prove the RTP path in both directions

Once the negotiated description is understood, test actual packet flow. Establish where caller-to-agent RTP is observed and where agent-to-caller RTP is observed, with source and destination tuples attached to each direction.

RFC 3550 defines RTP's sequencing and timestamping model. Those fields help analyze delivery, but packets alone do not prove that their payload contains intelligible speech.

A useful investigation compares adjacent observation points. If the sender emits packets but the next receiver sees none, the fault lies between those points or in the observations themselves.

You do not need to see every intermediate router. Find the narrowest boundary you can prove, then ask the owner of the next segment for matching evidence from the same controlled call.

flowchart TD
    A[Connected call with silence] -->|Inspect actual exchange| B{Valid media negotiation?}
    B -->|No| C[Repair SDP or supported formats]
    B -->|Yes| D{RTP reaches receiver?}
    D -->|No| E[Inspect routing NAT and firewall]
    D -->|Yes| F{Payload decodes correctly?}
    F -->|No| G[Inspect codec mapping and framing]
    F -->|Yes| H{Application receives speech?}
    H -->|No| I[Inspect input adapter and gating]
    H -->|Yes| J[Trace response and output playback]

This flow narrows the next test. It is a diagnostic method, not a claim that every silent call belongs to exactly one simple failure category.

NAT changes what addresses mean

A host behind NAT can advertise an internal address while sending packets through a translated external tuple. The remote side needs a reachable destination consistent with the deployment's supported NAT traversal behavior.

Symmetric RTP behavior can help some deployments learn a return path from received packets, but support and configuration vary. Verify the actual endpoint contract instead of assuming all SIP stacks use the same behavior.

Avoid treating a public IP in a configuration screen as proof of correct advertisement. The relevant evidence is the effective SDP and the packet tuples used during the failing call.

A SIP-aware gateway can rewrite messages, sometimes incorrectly. If a SIP ALG or session border controller is in the path, compare descriptions on both sides before changing application code.

Firewall rules must match media

Opening the signaling port does not automatically open the media range. RTP may use different UDP ports and addresses, and a stateful rule may allow one direction while blocking the return path.

Use the negotiated and documented media configuration to identify the needed rule. Do not respond to a silent call by opening all UDP traffic or disabling host protection globally.

If a provider requires a published source range, verify the authoritative current range. An undocumented guess based on one observed packet is insufficient for a durable allowlist and can fail when the provider changes infrastructure.

Capture the exact rejected or absent flow where possible. A firewall counter or adjacent packet capture is stronger evidence than assuming the firewall is responsible because the application works on a laptop.

Distinguish loss from absence

No observed packets is different from packet loss within an active stream. Sequence gaps, reordering, and jitter need an analysis window and a known observation point.

A receiver may discard late packets even when a network capture shows they arrived. That explains why a packet-level delivery rate can look healthy while audible output breaks up.

Do not compare jitter values without checking units and definition. RTP timestamp clocks, receiver timing, and dashboard aggregation can differ, so a number named jitter needs its measurement contract attached.

For intermittent audio, correlate packet behavior with application queue depth and scheduling. A busy event loop can starve media processing even when the network delivers packets on time.

The observability guide connects these views without pretending their clocks are identical. Preserve the distinction between packet arrival and application consumption.

Verify codec and audio interpretation

Once packets arrive, prove that the receiver interprets them using the negotiated format. A payload-type number is meaningful in the context of the RTP profile and the session's mapping.

RFC 3551 defines standard audio payload mappings in the RTP audio/video profile. In the synthetic SDP example, PCMU and PCMA are explicitly named at an 8 kHz clock rate.

A receiver that treats compressed telephony bytes as linear PCM can produce noise or unusable signal. A receiver that interprets sample rate, channel layout, or byte framing incorrectly can change timing and destroy recognition quality.

Check the boundary after decoding and before speech processing. A valid decoded synthetic phrase clears more of the path than a packet counter, while still avoiding the need to inspect real caller content.

Keep codec names exact

PCMU and PCMA are different companding formats. A system that supports one does not automatically support the other, even though both are commonly associated with G.711 telephony.

A generic label such as PCM is insufficient. Record the actual negotiated encoding and the format expected by the application adapter, including sample rate, channels, and sample representation after decoding.

Do not assume a codec offered by one endpoint was selected. Read the answer and the observed payload mapping, then verify the sender follows that result.

If a managed route supports only a narrow codec set, configure the carrier accordingly or use an explicitly supported transcoding boundary. Adding an unsupported format to a local offer cannot make the provider decode it.

Test timing and packetization

Packetization affects how much audio arrives per packet and how frequently the application receives it. A receiver expecting one frame size can mishandle another if its adapter incorrectly assumes fixed chunks.

Streaming audio code should respect the negotiated framing and the decoder's output contract. Avoid concatenating bytes into arbitrary sample arrays without verifying whether the source is compressed audio or already decoded samples.

RTP timestamps describe media timing in the stream's clock domain. They are not ordinary wall-clock milliseconds, and interpreting them as such can create incorrect pacing or misleading latency charts.

Use a known-duration synthetic tone or phrase to verify decoded duration and playback rate. The check should establish format correctness, not claim that a tone proves speech recognition or conversation quality.

Watch transcoding boundaries

A carrier, border controller, gateway, or application adapter may transcode audio. Each boundary can change format, timing, quality, and the evidence available to downstream systems.

Record the effective path rather than assuming one end-to-end codec. A call can negotiate one format on the carrier leg and another on the application leg, with a gateway responsible for translating between them.

If the gateway receives valid speech and emits silence, the investigation belongs at that boundary. If it emits valid audio that the application rejects, inspect the next adapter rather than blaming the carrier.

The multilingual evaluation guide matters after transport correctness. Recognition scores on clean audio do not qualify a transcoded phone path for every supported language.

Separate DTMF from speech

Touch-tone events can use a distinct RTP payload format. A system receiving DTMF successfully has not necessarily proved that its speech payload is correctly decoded.

RFC 4733 specifies RTP telephone-event transport. Match the negotiated event handling to the integration's supported contract instead of inferring it from the audio codec alone.

Likewise, an audible tone heard by one endpoint does not establish that an out-of-band event reached the application. Test the interaction mode your workflow actually uses.

Keep DTMF fixtures separate from speech fixtures. They can share the call harness while asserting different boundaries and different expected application events.

Inspect application and conversation boundaries

If the decoded input contains the expected speech, inspect how the application passes it to recognition or a realtime model. Media can be valid at ingress while an adapter drops frames, mislabels format, or never opens the input gate.

Record frame counts and decoded durations at adjacent application boundaries. The difference can reveal a queue that never drains, an early close, or an incorrect assumption about chunk size.

Use metadata before content. A controlled fixture already tells you what the phrase should be, so you can test the path without retaining arbitrary real-call audio in debugging logs.

Once the model receives speech, inspect endpoint acceptance and response generation. A system stuck waiting for a turn boundary can look silent even though its media transport is functioning correctly.

Confirm speech detection separately

A VAD event proves the detector observed a signal meeting its criteria. It does not prove the transcript is correct or that the caller has completed their turn.

The VAD versus turn-detection guide separates those decisions. A silence timeout set too long can delay response; a threshold set too high can miss quiet speech; the fixes differ.

Use a known fixture that includes both speech and a complete turn. If speech is detected but no endpoint is accepted, inspect the policy's reason and timer rather than changing carrier routing.

If an endpoint is accepted and no response begins, inspect workflow state, tool dependencies, provider errors, and output permissions. The workflow enforcement guide helps distinguish an intentional safe wait from a missing transition.

Trace output all the way back

A model can produce text while synthesis fails. Synthesis can produce bytes while the output adapter never packetizes them, and the sender can emit RTP while the caller's receiving path drops it.

Mark each boundary. Text available, audio available, encoded media sent, remote media received where observable, and audible playback are distinct facts.

Do not use TTS first-byte latency as proof that the caller heard a greeting. The latency guide explains the missing stages and how to label a measurement when playback is not observable.

For a controlled test, have the remote endpoint confirm the known phrase or inspect its authorized playback boundary. A server recording captured before the failing link cannot clear that link.

Check cancellation and call closure

A greeting can be generated and then canceled by a false interruption or premature call-close event. The resulting silence is an application-state problem even though media negotiation and synthesis both succeeded.

Trace the response generation identity and terminal reason. The interruption-safe state machine should reject stale output deliberately, while the trace explains why it was rejected.

Check whether a transport disconnect, browser close, or timeout invalidated the call before output. Shutdown semantics should preserve a faithful terminal reason instead of converting every close into normal completion.

A call can also close successfully while post-call processing fails. Keep those failures separate so a missing recording is not misdiagnosed as proof that the live media path was silent.

Qualify the 60db Agent SIP route

Use the current public BYO SIP documentation and the line setup result for the selected workspace. Do not copy a host from an old article, private implementation, or another environment.

The 60db BYO SIP documentation describes UDP signaling and plain RTP with PCMU or PCMA at 8 kHz for this route. It does not establish TLS or SRTP support on that integration.

That is a concrete security and compatibility boundary. If your deployment requires encrypted signaling and media, qualify another documented route or obtain a supported contract before sending the workload through this one.

Do not suggest enabling an unsupported encryption checkbox as a troubleshooting fix. A SIP endpoint expecting plain RTP and a peer sending SRTP will not become compatible through optimistic configuration.

Verify availability before media diagnosis

Agent access and inbound routing can be workspace or environment gated. A setup or check response indicating inbound is disabled is an availability result, not a silent-media defect.

Use the destination returned by current setup and follow the documented line-check procedure. Keep credentials in the approved secret store and redact them from screenshots, support bundles, and copied command output.

Third-party carrier recipes in the public documentation are marked untested, and hosted source addresses are not yet published there. Treat those limits as qualification questions rather than filling gaps with guessed firewall ranges.

For an outbound test, use an authorized destination and a known synthetic script. For inbound, proceed only where enabled and verified for the specific workspace and environment.

Read error codes as starting points

The documented route includes signaling errors such as 403, 404, 486, and 488. Interpret the actual response and context rather than turning one code into a universal root-cause rule.

A refusal can involve authorization or route policy; a destination problem can involve addressing; a busy result describes a different state from an incompatible media description. The provider's detailed diagnostic and the failing exchange own the conclusion.

Do not retry every error indefinitely. Repeated attempts can create cost, rate pressure, and confusing evidence while leaving the underlying configuration unchanged.

Attach the call identifier, timestamp, direction, redacted signaling result, and exact line-check outcome to a support request. That gives the next owner a bounded reproduction without exposing credentials or caller content.

Keep product claims within observed boundaries

No live SIP qualification was run for this article. The route capabilities above are documented facts, while the diagnostic sequence is a proposed method for the reader's environment.

The series contains no measured rate of silent calls, no carrier reliability ranking, and no claim that a particular NAT setting fixes every deployment. Those would require a defined cohort and controlled evidence.

For 60db Agent, documented analytics can supplement the investigation where available. They do not replace packet or receiver evidence for a boundary the managed interface does not expose.

The cost-per-success guide explains why failed and repeated test attempts still belong in accounting. A normal hangup or connected status should never be promoted into business success merely to make the test report look better.

The next test should follow the last boundary with credible evidence.

Turn the diagnosis into regression coverage

Once the last unproved boundary is repaired, replay the original controlled fixture. Confirm both directions and the full task, rather than stopping when a connected status returns.

Keep one regression for the mechanism that failed. A private-address advertisement defect needs an SDP or route assertion; a decoder mismatch needs a format fixture; stale playback needs a cancellation assertion.

Use a limited live smoke test for the real route after deterministic checks pass. A local unit test cannot prove carrier reachability, but a live call alone cannot cover all format and state-machine branches reliably.

Define a practical acceptance record

The record should identify the route and configuration version, test time, negotiated codec, direction-specific media evidence, decoded fixture result, audible response confirmation, and final task outcome.

State unknowns explicitly. If the provider does not expose a receiver counter, record that gap instead of substituting a guessed zero-loss figure.

Include teardown. Test calls should end, media resources should release, and post-call jobs should reach their own terminal states without leaving sessions running indefinitely.

A shutdown regression is especially useful after fixing a route that previously hung. Restored audio should not come with leaked calls or a repeated callback loop.

Test the negative cases deliberately

A passing call should be accompanied by a failure that your diagnostics identify correctly. In a controlled test environment, reject an unsupported media format or route a synthetic fixture to an intentionally unavailable receiver, then verify that the report names the failed boundary without claiming model failure.

Keep such tests isolated from production traffic. The purpose is to validate the harness and diagnostic contract, not to modify live firewall policy or create failures for unrelated callers.

Verify timeout behavior as part of that test. A missing media stream should produce a bounded, explicit terminal outcome and release resources, rather than leave an apparently connected call waiting until a large account-level limit eventually stops it.

Also test an application-level silence case with valid media. Feed a known silent fixture through the supported path and confirm that packet reception remains distinguishable from speech detection and conversational progress.

These counterexamples protect the meaning of your evidence. A dashboard that reports healthy audio whenever packets exist will fail this test, and a harness that reports success whenever a call answers will fail it too.

For each negative case, record the expected error category before execution. That prevents the team from accepting whatever label the system happened to emit and calling the test a pass after the fact.

The same technique applies after a provider migration. Reuse the outcome definitions and controlled failures so differences in provider status vocabulary cannot silently change your success denominator.

Preserve the repair's boundary

Document the specific configuration or code change that restored the path and the evidence that verified it. Avoid a broad statement such as "fixed SIP" when the repair concerned one NAT translation or one payload mapping.

Remove temporary diagnostic capture and return logging to its approved level. A successful incident response should not leave broad packet collection or sensitive debug output enabled.

Keep a rollback path for the changed configuration. If a later carrier or gateway update invalidates the assumption, operators need to know which contract to requalify and which test reproduces it.

The result is a smaller, stronger operational artifact: a known route, an explainable failure mechanism, and a regression that proves the repaired boundary remains intact.

Frequently asked questions

Why can SIP connect with no audio?

SIP signaling and media delivery use distinct negotiated paths. The call can answer while RTP is blocked, misrouted, incorrectly decoded, or discarded by the application.

What causes one-way audio?

One direction can fail because of an unreachable advertised address, asymmetric firewall behavior, incorrect return-path handling, or a receiver problem. Prove each direction with adjacent packet and decode observations before choosing a cause.

Does a 200 response prove audio works?

A successful SIP response establishes the relevant signaling result. It does not prove that either endpoint receives intelligible speech or that the caller hears the agent's output.

What should I inspect first?

Confirm the exact failing dialog and its actual offer and answer. Then inspect effective media addresses, ports, direction, and formats before moving to packet flow and decoding.

Is opening the SIP port enough?

Signaling access does not automatically permit media traffic. Match firewall rules to the supported media configuration and observed negotiated flow rather than opening all UDP traffic.

What is SDP used for?

SDP describes media-session properties such as addresses, ports, formats, and direction. The offer/answer exchange determines the effective negotiated result for the call.

Can NAT cause silent calls?

NAT can make advertised media addresses or return paths unreachable. Verify actual SDP and packet tuples because a configuration screen alone does not prove correct translation.

Should I disable the SIP ALG?

A SIP ALG can alter signaling, but its presence is a hypothesis rather than proof of failure. Compare messages across that boundary and follow the network's supported configuration before changing it.

What does an RTP packet counter prove?

It proves packets were observed at a particular boundary under that counter's definition. It does not prove the payload decodes into speech or reaches remote playback.

Can silence be valid media?

A stream can carry digital silence, comfort noise, or muted input while packet counters increase. Use a controlled synthetic speech fixture to test content at the decode boundary.

Why is the audio garbled?

Incorrect codec mapping, sample interpretation, framing, or transcoding can corrupt audio despite successful packet delivery. Compare the negotiated format with what the receiver actually decodes.

Are PCMU and PCMA interchangeable?

They are different companding formats and require correct negotiation and decoding. Configure the supported format explicitly rather than assuming a generic PCM label covers both.

Does DTMF success prove speech works?

DTMF can use a separate telephone-event payload path. Test speech decoding and DTMF handling independently even when they share the same call.

Why does audio fail after transfer?

Transfer can create a new media leg or renegotiate destinations and direction. Compare the effective media state before and after the transfer and verify both paths again.

Can a prompt cause a silent call?

Conversation policy can prevent response after valid audio arrives, but it cannot repair missing RTP. Establish transport and decoded input before investigating endpointing, workflow, or prompt behavior.

Does 60db Agent SIP support TLS and SRTP?

The documented BYO SIP route reviewed here uses UDP and plain RTP. If encrypted signaling or media is required, obtain a supported route contract rather than assuming those options are available.

Which host should I configure?

Use the current destination returned by the selected workspace's line setup. Do not reuse a copied host from an article, private implementation, or unrelated environment.

Can I assume inbound is enabled?

Inbound availability can be workspace and environment gated. Verify the setup and check response before treating an inbound failure as a media defect.

Should I upload packet captures to support?

Share only the minimum authorized diagnostic artifact through the approved channel. Captures can expose signaling identifiers and media, so redact or use a synthetic reproduction and apply retention controls.

What proves the repair is complete?

The original controlled call should pass both media directions, decoding, audible response, and the intended task. Add a mechanism-specific regression and verify that calls and diagnostic resources close cleanly.

Repair the last unproved boundary

Silent calls become manageable when the investigation follows the actual path. Establish signaling, negotiated media, packet delivery, decoding, application input, response generation, and remote playback as separate claims.

Use controlled fixtures and narrow observations before collecting sensitive payloads. Keep hypotheses attached to tests, change one relevant boundary at a time, and preserve unknowns instead of filling them with optimistic dashboard values.

For 60db Agent, qualify the documented route for your workspace, use the destination returned by setup, and respect its UDP, codec, and plain-RTP boundaries. No article can substitute for that environment-specific check.

The next step is one short authorized test call with a known phrase in each direction. Find the last boundary with evidence, repair the next one, and retain the smallest regression that proves the same fault cannot quietly return.