voip-telephony

Reload, never restart

This is the rule that separates someone who works on a PBX from someone who has just dropped every call in progress. A restart tears down active calls; a reload re-reads config and leaves them up.

run_command   asterisk -rx "dialplan reload"
run_command   asterisk -rx "sip reload"       (chan_sip)
run_command   asterisk -rx "pjsip reload"     (chan_pjsip — current)
run_command   kamailio -c                     (check config FIRST)
run_command   kamctl restart                  (only when genuinely needed)

Check before you reload. asterisk -rx "dialplan show" parses what is loaded; kamailio -c validates the config file without touching the running process. A reload of a file with a syntax error can leave you worse off than before it.

Before anything that could interrupt: asterisk -rx "core show channels". If calls are up, say so and let a person decide the moment.

-rx is how you talk to a running Asterisk

asterisk -rx "<command>" sends one command to the running daemon and returns. Plain asterisk -r opens an interactive console that will hang here, waiting for input nothing can send. Never use it in a run_command.

The questions, in the order they answer things

• Is the endpoint registered? pjsip show endpoints / pjsip show registrations, or sip show peers on chan_sip. An unregistered extension explains every symptom below it, so check this first.
• Which trunk, and is it up? pjsip show endpoint <name> — look at the status and the transport.
• Where does the call go? dialplan show <exten>@<context> — the context is what actually decides routing, and a call landing in the wrong context is the commonest "it dials but nothing happens".
• What happened live? core set verbose 3 then watch — as a job, because a log follow never returns: job_start "asterisk -rvvv" … job_abort when done. Same for journalctl -u asterisk -f.

No audio and one-way audio are network problems, not PBX problems

This is the single most common Asterisk/Kamailio call, and the diagnosis is almost never in the dialplan:

• One-way audio is almost always NAT: RTP is going somewhere that cannot reach back. Check external_media_address / external_signaling_address and local_net in pjsip.conf (externip/localnet on chan_sip).
• No audio at all is usually the RTP port range blocked — 10000–20000 UDP by default in rtp.conf. run_command "ss -ulpn | grep asterisk" shows what it is actually listening on; the firewall is the other half.
• Codec mismatch shows as a call that connects and drops immediately. The verbose log names the codecs both sides offered.

Prove it with a capture rather than a theory: job_start "tcpdump -n -c 500 -i any port 5060 -w /tmp/sip.pcap", place the call, then read it. Scope the capture to the port and bound it — a shared machine's traffic is not yours to hoover up.

Kamailio is a proxy, not a PBX

It routes SIP; it does not usually touch media. So when audio is broken and Kamailio is in the path, look at whether RTPProxy/RTPEngine is running and whether record_route() is being called — a missing record_route means in-dialog requests bypass the proxy and end up nowhere.

kamctl ul show lists current registrations; kamcmd is the runtime control if the ctl socket is enabled.

Credentials

A SIP secret in a config file is normal; a SIP secret in a tool argument is not. When editing pjsip.conf or a Kamailio subscriber, have the person supply the password directly — the rule in your system prompt applies. And a sip.conf readable by everyone is a finding worth reporting.