01 / 04
1. Check which SIP stack is loaded
- Connect to the correct server and inspect loaded channel modules.
- If PJSIP is present, use the PJSIP commands below. A legacy SIP phone instead uses the chan_sip commands available on that installation.
- Run `ss -lntu` on the server to inspect listening sockets, then compare the ports with `pjsip show transports`; PJSIP and chan_sip need not use the same port. Socket output alone does not identify the owning SIP stack or prove network reachability.
- Before you use it
- Run on the relevant Asterisk server with authorized CLI access; output may contain operational identifiers.
asterisk -rx 'module show like chan_pjsip'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
- The installed module and transport list are displayed.
- Stop if
- If a command is unavailable, check the installed driver and version before using a different command.
Recorded listening sockets
Open to enlarge
Capture details
The adjacent Asterisk driver commands are reader-run examples and are not shown executing here.You should seeA loaded module identifies the stack, not whether a particular device is reachable.
02 / 04
2. Inspect the endpoint and contact
- On the server shell, run `asterisk -rx "pjsip show endpoints"` and locate your test endpoint by its configured ID. These are Asterisk CLI commands passed through the shell, not ordinary shell commands.
- In the Asterisk console, run `pjsip show endpoint <ID>` and `pjsip show aor <ID>`, substituting the observed endpoint and AoR names; they need not match. Alternatively, pass each complete command in quotes to `asterisk -rx` from the server shell.
- For a registering phone, check that its AoR has a current contact. For an IP-authenticated trunk, compare its static contact and identification with the provider’s specification.
You should seeA contact supports routing to an address; it does not itself prove two-way audio.
03 / 04
3. Separate call signaling and audio
- Place one authorized test call and record whether it rings, answers, and has sound in each direction.
- If signaling fails before answer, inspect endpoint identification, route and provider response. If answered but silent, compare negotiated codec, SDP media addresses and RTP reachability on both legs.
- For a browser phone, also check microphone permission, trusted HTTPS/WSS certificate and browser audio device selection.
You should seeAn answered SIP call alone does not establish an RTP path. Compare observations at both ends before changing NAT or firewall settings.
04 / 04
4. Isolate and repeat
- Compare the same endpoint with an internal test destination, then compare a known-working endpoint on the same network.
- Record which side could hear, time and the single difference tested; share sanitized findings with the telephony owner.
- After an approved correction, repeat the same test in both directions.
You should seeA repeatable comparison narrows the fault to a device, route or media path; it does not certify a carrier.
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.
Primary references
Sources
- Asterisk PJSIP troubleshootingAsterisk · accessed November 4, 2026
- VICIdial PJSIP supportVICIdial Group · accessed November 4, 2026
- Configuring Asterisk for WebRTC clientsAsterisk · accessed November 4, 2026