Inbound call has dead air or delayed audio

Source and affected scope

Configuring res_pjsip to work through NAT ↗

Source date

Not stated in source

Source checked

2026-11-07

Reported version

Version-specific behavior; inspect the installed release

Guide updated

2026-11-07

• An answered inbound call has one-way or delayed audio; the symptom has multiple possible causes.

Before you start

• Authorized isolated lab and consenting test participants; record server/build and before-state.
• Never publish real phone numbers, network addresses, credentials, call audio or database rows.

Diagnose the reported problem

1. Step 1Compare the two call paths

   In an authorized lab, compare an internal call and one approved inbound test, noting which participant hears silence and exact start time. Identify each leg and server.

   Inspect endpoint and transport in Asterisk; replace TEST_ENDPOINT with the known lab endpoint. This is a point-in-time configuration view, not packet proof.

   Before you use it

   Run only on an authorized isolated lab or approved read-only diagnostic session; substitute placeholders. Preserve sensitive data privately.

   asterisk -rx 'pjsip show endpoint TEST_ENDPOINT'asterisk -rx 'pjsip show transports'

   Reader-run example · not executed for this guide

   This example has no recorded result here. Follow its preparation, expected result and stop conditions before using it.

   Success looks like

   If both calls fail, investigate the common endpoint and media path; inbound-only failure narrows attention to the carrier leg or its path.

   Stop if

   Stop if you cannot identify the test legs; do not change NAT or firewall settings based on symptom alone.

   Expected observation

   If both calls fail, investigate the common endpoint and media path; inbound-only failure narrows attention to the carrier leg or its path.

   If this check fails

   Stop if you cannot identify the test legs; do not change NAT or firewall settings based on symptom alone.

2. Step 2Compare signaling and media evidence

   For one approved synthetic call, identify the peer address actually negotiated for this leg and run ip route get for that address on the Asterisk media host. The output’s dev value names the outbound interface; check with the network owner whether the inbound path uses that interface too. Replace both placeholders only with this test’s authorized address and interface.

   Store the bounded packet capture in a new private directory; the example stops after 15 seconds or 400 packets and filters UDP to the one peer. It can contain identifiers and media: restrict access, follow retention rules, and never attach it to a public ticket.

   Separately obtain the authorized signaling/SDP evidence for the same leg and time; UDP packet capture alone does not show SIP over TLS or WSS. Compare advertised SDP c= and m= address/port with the actual UDP source and destination in the decoded packet headers.

   Fictional example: SDP advertises private 10.0.0.5:10020 to an external peer; the permitted capture shows packets sent toward a different public endpoint and none arriving at the advertised private address. This narrows an address/NAT hypothesis; it does not prove root cause or decoded audio.

   Before you use it

   Run only with written authorization on an isolated test; confirm tcpdump, timeout and the routed interface first. Start the approved call within the 15-second window. Packet data is sensitive.

   # Replace both placeholders with the approved test peer and route interface.TEST_PEER='<TEST_PEER_IP>'IFACE='<ROUTE_INTERFACE>'ip route get "$TEST_PEER"umask 077CAP_DIR=$(mktemp -d "${TMPDIR:-/tmp}/vicigeek-rtp-test.XXXXXXXX")printf 'Private capture directory: %s\n' "$CAP_DIR"sudo timeout 15s tcpdump -i "$IFACE" -nn -s 0 -c 400 -w "$CAP_DIR/media.pcap" "udp and host $TEST_PEER"# A timeout exit can be expected after 15 seconds; inspect the saved headers privately.sudo tcpdump -nn -r "$CAP_DIR/media.pcap"

   Reader-run example · not executed for this guide

   This example has no recorded result here. Follow its preparation, expected result and stop conditions before using it.

   Success looks like

   The capture contains time-stamped UDP packets for the approved peer; compare directions, port and timing with separately obtained SDP. A packet is not proof of audible audio.

   Stop if

   Stop if the interface, peer or consent is unknown. An empty trace can mean the wrong interface/filter or no packets; do not infer a NAT defect from it alone.

   Expected observation

   Each side’s negotiated address and observed packets align with the intended path; both directions deliver packets during the missing-audio interval.

   If this check fails

   Packets in both directions do not prove decoded audio; if addresses match investigate codecs, endpoint playback and timing instead.

Correct the confirmed cause

Use this branch only when your diagnostic observations match the affected scope above. The lab result states which outcomes were actually tested.

1. Step 3Correct the identified boundary

   Record the current transport and endpoint settings and network rule, owner and rollback. Have the owner change only the demonstrated wrong advertisement, NAT mapping or approved rule using the installed version’s normal procedure.

   Expected observation

   One change targets a measured mismatch.

   If this check fails

   Do not enable broad RTP exposure or change codecs, NAT and firewall together.

Verify the outcome

• Repeat the same authorized internal and inbound tests; record both listeners’ observations and the same packet timing. Confirm no regression and compare to the original trace.

Recover or roll back

• Restore the exact recorded transport or network setting through the approved change process; repeat the same tests. Retain traces securely.

Screenshot evidence

No native screenshot is attached to this guide.

• Configuring res_pjsip to work through NAT · Primary documentation; checked 2026-11-07