Freeze the first wrong observation
Record timestamp and timezone, installed Asterisk release, dialplan location, channel technology, name, unique ID and linked ID, requested CHANNEL() selector, returned value, call direction and the SIP message or policy expectation used for comparison. Classify the symptom as empty value, wrong URI, swapped local and remote meaning, wrong Call-ID or tag, unexpected secure flag, wrong socket address, or mismatch with packet evidence.
Do not begin by rewriting headers or transport settings. The current channel and selector contract define what the value can mean.
Prove the current leg is PJSIP
Check CHANNEL(channeltype) and the actual executed dialplan leg. PJSIP-specific items return empty when unavailable on the current channel. If execution is on Local, DAHDI or another technology, or on the opposite bridge leg, move the observation to the intended PJSIP channel rather than interpreting blank output as a missing SIP field.
For a newly created outbound channel, use an appropriate pre-dial handler when evidence is needed before the request leaves. Lowercase b() runs on each callee channel; uppercase B() runs on the caller.
Match the selector to its documented object
Compare request_uri with the original inbound INVITE that created the channel, target_uri with the send target, and local or remote URI and tag with the dialog side relative to this channel. Compare call-id with the same dialog leg, not merely another message sharing the linked ID.
If the goal is one URI component, preserve the complete URI and parse it afterward. Do not manually split IPv6 literals, escaped users or parameters and call the result equivalent.
Interpret addresses by direction
On an inbound channel, local_addr is the address and port that received the INVITE and remote_addr is the source. On an outbound channel, they are the source and destination used to transmit the INVITE. Record direction before comparing either value with a firewall, proxy or capture.
Keep those socket addresses separate from URI hosts, DNS results, outbound-proxy targets, Contact values and RTP source or destination addresses.
Keep secure signaling narrower than trust
If CHANNEL(pjsip,secure) is zero or unexpected, verify the actual transport on the same leg. If it is one, retain certificate-validation, next-hop identity, intermediary boundaries, media protection and peer policy as separate checks. A secure transport flag is not end-to-end identity proof.
Compare Asterisk-side evidence with the next hop before changing certificates, endpoint transports or firewall policy.
Correct one owner and repeat a control
Correct only the demonstrated mismatch: channel technology, caller-versus-callee placement, pre-dial timing, selector choice, direction interpretation, parser use, endpoint association or intermediary expectation. Preserve the previous dialplan and a rollback.
Repeat the affected case and one known-good control. Acceptance requires the expected value on the exact leg plus matching SIP or transport evidence; it does not imply successful routing, media or call completion. No PBX, endpoint, channel, URI, address, packet or call was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk CHANNEL dialplan function ↗
- Asterisk PJSIP_ENDPOINT dialplan function ↗
- Asterisk PJSIP_PARSE_URI dialplan function ↗
- Asterisk pre-dial handlers ↗
- RFC 3261: SIP ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.