1. Write down the symptom
- During one supervised test call record the test time and route, the endpoint used, and whether each side hears the other: for example Agent → test endpoint: heard / not heard; test endpoint → Agent: heard / not heard.
- Repeat using a second headset or endpoint on the same connection, then the first endpoint on a different approved connection. Keep the campaign, destination and test length consistent where possible.
- For each comparison record the selected microphone and speaker, codec if known, and whether the symptom is silence or choppiness. Record unknown values as unknown; do not copy real addresses or customer details into the worksheet.
You should seeA symptom that follows one headset or network points to that leg; a single call is not a conclusive diagnosis. No call or audio measurement was recorded for this guide.
2. Check the endpoint before the trunk
- Confirm the correct microphone and speaker are selected, unmuted, and permitted in the browser or softphone.
- For PJSIP, check the endpoint and its AoR with `pjsip show endpoint <ID>` and `pjsip show aor <AOR>` on the assigned server.
- If a browser phone does not connect, check the trusted certificate and WSS connection before diagnosing call audio.
You should seeA contact or connected browser session helps establish signaling only; it does not prove audio.
3. Compare the two media legs
- On the test call, compare the negotiated codec and SDP media address for each leg with the network and carrier's expected addresses.
- Ask the network owner to check packet loss, jitter and reachability on the relevant RTP paths for the test window.
- If one-way audio occurs only through a carrier, provide the carrier the sanitized time, direction and call identifier through its approved support channel.
You should seeUnreachable media addresses or loss on one leg are actionable observations; do not change NAT settings based solely on a symptom.
4. Change one verified cause and repeat
- Record the original value before an authorized configuration change; apply one change through the supported owner-managed path.
- Repeat the same internal and carrier tests and compare both audio directions.
- If the condition worsens, restore the recorded value and recheck; escalate with the before-and-after results.
You should seeA successful repeat requires both parties to hear clearly for the test interval. No audio test was performed for these screenshots.
Checks and sources
What was checked
- Instructions are based on the linked project documentation and sanitized interface captures. The captures do not prove registration, a completed call, a transfer, callback or audio quality.
- The lab runs VICIdial SVN 4037, database schema 1748 and Asterisk 18.26.4-vici. Labels, enabled features and provider requirements can differ on another installation.
- No controlled test call, two-way audio or RTP quality measurement was recorded. The linked Asterisk troubleshooting references support the diagnostic checks; the steps describe expected comparisons without claiming an observed audio result.
Primary references
Sources
- Asterisk PJSIP troubleshootingAsterisk · accessed November 4, 2026
- Configuring Asterisk for WebRTC clientsAsterisk · accessed November 4, 2026