VoIP.infoThe independent guide to business communications.
VoIP.info Operations guide

Asterisk PJSIP connected-line and redirecting identity: trust, send and update boundaries

Keep caller, connected-line and redirecting identities separate across initial setup, answer, forwarding and transfer updates.

Reviewed 2026-10-11Asterisk 22 party-ID, CONNECTEDLINE, REDIRECTING, res_pjsip endpoint, Dial, Queue, interception-routine and AMI NewConnectedLine documentation reviewed October 11, 2026; no PBX, endpoint, provider, identity, privacy value, dialplan, SIP message, forward, transfer, display, AMI event or call was inspected or testedAdvancedDocumentation based · not lab tested

Keep the three party identities separate

Caller ID describes the party that originated a call. Connected-line identity describes the party at the far end of an established call and can change after a transfer. Redirecting identity describes the parties involved when a call is forwarded, including where it came from and where it is going. A familiar number can appear in more than one structure without those structures becoming interchangeable.

For one approved call, name the inbound and outbound channels, original caller, dialled target, connected party, redirecting-from and redirecting-to identities, presentation values and the time each value changed. A phone display, CDR field or SIP header is one observation, not the complete party model.

Map identity to the channel and call phase

Asterisk documents CALLERID on the channel from the originator and CONNECTEDLINE as the identity across the bridge. On the opposite channel their roles reverse. Local channels add another paired boundary, so a value read on Local/...;1 cannot be assumed to be the same field on Local/...;2 or either PJSIP leg.

Preserve the values before Dial or Queue, at provisional response, at answer, after bridge creation and after each blind or attended transfer. Connected-line updates can travel while a call is established; redirecting information normally belongs to routing before answer. The last display seen by an endpoint does not identify which phase or leg produced it.

Read the loaded PJSIP send and trust controls

PJSIP endpoints expose separate controls including trust_connected_line, send_connected_line, connected_line_method, rpid_immediate, send_diversion and send_history_info. They govern different directions and message behavior. Inspect the loaded endpoint on both call legs and retain the actual SIP messages before changing a template.

trust_connected_line decides whether Asterisk accepts connected-line updates from an endpoint; send_connected_line decides whether it sends updates toward that endpoint. Diversion and History-Info controls concern redirecting history. These options do not authenticate an asserted public identity, authorize a carrier number or prove that a handset supports or displays the resulting update.

Update complete values through supported functions

The CONNECTEDLINE() and REDIRECTING() functions expose name, number, presentation, source, tag, reason and count data. Their i form inhibits an immediate channel-driver update while related subfields are assembled. Set the complete intended state, then allow one update; otherwise a peer can observe a partial name, number or presentation combination.

For reusable policy, Asterisk documents interception routines based on Gosub, with explicit Return. The older interception macros are deprecated. Preserve the tag and original values, avoid destructive normalization before evidence is captured and keep privacy presentation with the identity it qualifies.

Understand the Dial and Queue suppression boundary

Dial and Queue provide an uppercase I option that blocks connected-line and redirecting updates during the dial attempt. Asterisk describes it as a broad control: it blocks redirecting updates and the initial answer connected-line update, while a later transfer update can occur after the application has completed.

Use that option only when the intended policy is explicit. It can preserve a pre-set identity, but it can also hide a legitimate answered or forwarded party. Prove whether the incorrect display came from received identity, dialplan mutation, application suppression, PJSIP send policy, SIP signaling or endpoint presentation before adding I.

Accept identity, privacy and display independently

Retest direct answer, busy or no-answer forwarding, blind transfer, attended transfer, queue delivery and any Local-channel or trunk path in scope. Preserve the Asterisk values, NewConnectedLine event where used, outbound SIP update, remote response and endpoint display as separate outcomes.

A correct internal value does not prove a header left Asterisk; a correct header does not prove the peer trusted or displayed it. An accepted carrier message does not authorize arbitrary caller or connected identity. Keep privacy, numbering format, provider policy and jurisdictional requirements in the acceptance record. This workflow is documentation-derived and was not reproduced on a customer or laboratory PBX.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Diagnostic · Asterisk 22 party-ID, CONNECTEDLINE, REDIRECTING, res_pjsip endpoint, Dial, Queue, interception-routine and AMI NewConnectedLine documentation reviewed October 11, 2026; no PBX, endpoint, provider, identity, privacy value, dialplan, SIP message, forward, transfer, display, AMI event or call was inspected or tested

Asterisk shows the wrong connected party or diversion after a transfer or forward

Trace the identity from channel state through dialplan policy, loaded PJSIP controls, SIP updates and the endpoint display.

Read guide →
Guide · Current Asterisk feature-transfer architecture, Asterisk 22 features, FEATUREMAP, BlindTransfer and AttendedTransfer references plus AMI and CEL transfer-event specifications reviewed October 6, 2026; no PBX, endpoint, phone, channel, bridge, dialplan destination, feature code, DTMF sequence, native SIP transfer, recording, identity, media path or call was inspected or tested

Asterisk call transfers: blind, attended and bridge evidence

Separate core feature-code transfers, native SIP or phone behavior and dialplan transfer applications, then preserve the original bridge, consultation leg, destination and final bridge as distinct evidence.

Read guide →
Guide · Current Asterisk PJSIP header, inheritable-header, header-list, header-parameter, response-header and pre-dial-handler documentation reviewed October 8, 2026; PJSIP_INHERITABLE_HEADER is documented from 20.19.0, 22.9.0 and 23.3.0, and no PBX, dialplan, channel, header, provider, endpoint, request, response, registration, authentication exchange, availability, compatibility or call was inspected or tested

Asterisk PJSIP outbound headers: channel ownership, inheritance and proof

Put a required SIP header on the channel that will send it, distinguish direct from inherited headers and verify the emitted request.

Read guide →
Guide · Asterisk Local Channel, ARI channel, AMI v2 and CDR documentation reviewed October 6, 2026; exact behavior remains dependent on the installed Asterisk build, dialplan, applications, channel technologies, bridges and record backends, and no PBX, Local channel, queue, callfile, channel variable, bridge, event, record, endpoint, media path or live call was inspected or tested

Asterisk Local channels: pairs, optimization and retained behavior

Use Local channels for internal dialplan legs while distinguishing their two halves, default optimization, retained behavior, bridge events and call-record evidence.

Read guide →
Guide · Asterisk 22 LTS

Asterisk dialplan: contexts, patterns and loaded-call evidence

Build a restricted Asterisk 22 call path, then prove its context, match, priorities and runtime behavior separately.

Read guide →
Troubleshooting · Current Asterisk res_pjsip, party-ID, CALLERID and BLACKLIST references; FreePBX Blacklist 17.0.1.2 release/17.0 metadata and current source; plus FreePBX 17 on Debian 12 reviewed October 11, 2026; Sangoma GUI 13 screen guidance is version-scoped, and no PBX, carrier, blacklist rule or live call was inspected or tested

Caller ID is missing or wrong

Trace calling, connected and redirecting identity across FreePBX policy, Asterisk channel state, SIP headers and carrier treatment.

Read guide →
Troubleshooting · RFC 3515, RFC 5589 and current Asterisk transfer documentation reviewed October 5, 2026; the September 16, 2026 Asterisk issue is an open single-environment report, not a reproduced or universal defect

SIP REFER transfer accepted but the call does not connect

Trace the actual transfer mechanism, REFER authorization, accepted request, notification subscription, referred call leg, attended-dialog replacement and final bridge separately.

Read guide →