Asterisk PJSIP channel signaling context: URI, tag and socket evidence

Start with the exact current channel

CHANNEL() reads the current channel unless dialplan execution has deliberately moved to another leg. Confirm CHANNEL(channeltype), CHANNEL(name), CHANNEL(uniqueid) and CHANNEL(linkedid) before reading PJSIP-specific data. A caller channel, an outbound callee, a Local-channel half and a bridge peer can share one call story while retaining different signaling context.

Asterisk documents that a requested item unavailable on the current channel returns an empty string. An empty PJSIP value can therefore mean wrong technology, wrong leg, wrong timing or unavailable data; it is not automatically evidence that the received SIP message omitted the field.

Keep dialog identity fields distinct

CHANNEL(pjsip,call-id) returns the SIP Call-ID for the current PJSIP channel. local_uri and local_tag describe the local dialog identity, while remote_uri and remote_tag describe the remote dialog identity. RFC 3261 defines a dialog using Call-ID plus local and remote tags, so none of those values is a substitute for the complete tuple.

Local and remote are relative to the current channel, not permanent labels for an organization, user or network side. When the call has two PJSIP legs, each leg can have its own dialog and Call-ID.

Separate target, request and dialog URIs

target_uri is the contact URI where requests are sent. request_uri is documented as the Request-URI of the incoming INVITE that created the channel. local_uri and remote_uri instead describe dialog parties. Preserve those meanings before parsing a user, host, port or parameter.

A redirect, contact resolution, outbound proxy, routing header or later target refresh can make the send target differ from the original inbound Request-URI. A returned URI is syntax evidence; it does not prove endpoint authorization, DNS resolution, selected route or packet delivery.

Read transport security and socket addresses separately

CHANNEL(pjsip,secure) reports whether signaling on the current channel uses a secure transport. It does not establish peer identity, certificate validation, media encryption or an end-to-end protected path through intermediaries.

local_addr and remote_addr are direction-aware socket evidence for the INVITE: on inbound calls they describe where it was received and where it came from; on outbound calls they describe where it was transmitted from and to. These values are not the same as URI hosts, Contact targets, endpoint names or RTP addresses.

Bind endpoint and contact evidence to the same leg

CHANNEL(endpoint) identifies the endpoint associated with the current PJSIP channel. Asterisk says CHANNEL(contact) and CHANNEL(aor) may be absent and are available only on outgoing legs when present. Use PJSIP_ENDPOINT(), PJSIP_CONTACT() and PJSIP_AOR() for the corresponding object fields instead of treating their names as SIP addresses.

Inbound identification, endpoint policy, authentication, AoR inventory, selected contact, channel creation and dialog signaling remain separate evidence stages.

Capture once, redact, and compare with the wire

For a bounded diagnostic, record the exact channel identifiers, PJSIP selector, returned value and timestamp before the leg changes or hangs up. Parse URI parts only after preserving the complete redacted value. Avoid long-lived logging of user information, addresses or tokens.

Compare the channel values with the corresponding INVITE and dialog messages on the same leg. Accept the observation only when direction, leg and timing agree; then follow the selected route, peer response and media separately. No runtime value or call was tested for this guide.

Continue from signaling sockets to media-stream evidence

local_addr and remote_addr describe SIP INVITE sockets. The RTP channel-context guide separately handles local, remote and direct-media addresses, encryption and hold.