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

Freeze one wrong display and its timeline

Record timestamp and timezone, Asterisk version, inbound and outbound unique IDs, original caller, dialled target, connected party, redirecting-from and redirecting-to parties, transfer type, forwarding reason, presentation state, expected display, observed display and the first moment it became wrong. Preserve sensitive identities outside shared tickets.

Classify whether the symptom exists before answer, at answer, after a blind or attended transfer, only through a queue or Local channel, only on one endpoint, or only across one trunk. Those timelines select different owners.

Read party state on the correct channel

Capture CALLERID, CONNECTEDLINE and REDIRECTING fields on each relevant channel before Dial or Queue, at answer and after the transfer or forward. Preserve number, name, presentation, source, tag, reason and redirect count where available. Do not compare a caller field from one leg with a connected-line field from the other and call the difference corruption.

If Local channels are present, keep the ;1 and ;2 halves separate and follow optimization or retained-channel behavior. Confirm the actual bridge members and transfer result before editing a global identity routine.

Compare loaded endpoint controls with the signaling

Read the loaded source and destination PJSIP endpoints. Preserve trust_connected_line, send_connected_line, connected_line_method, rpid_immediate, send_diversion, send_history_info, and related PAI or RPID controls separately. Then inspect the initial INVITE, provisional and final responses, and any UPDATE or re-INVITE carrying identity.

If Asterisk has the intended value but sends no update, the send or method boundary is implicated. If the peer sends an update that Asterisk does not accept, inspect trust policy. If the correct update leaves Asterisk but the display stays wrong, move to peer support, privacy and presentation rather than rewriting the dialplan.

Find dialplan mutation or suppression

Search the loaded path for CONNECTEDLINE and REDIRECTING writes, interception routines, inherited variables, Dial or Queue options and custom transfer handling. The i function option should group a complete update, while the applications' uppercase I suppresses updates during the dial attempt. They solve different problems.

A pre-set connected identity can be overwritten by an answer update unless policy intercepts or suppresses it; broad suppression can hide a legitimate destination. Preserve the original value and change only the routine, field or application boundary that first diverges.

Separate forwarding history from transfer identity

For forwarding, retain redirecting-from, redirecting-to, original redirector, reason and count, then compare Diversion or History-Info signaling and the receiving peer's policy. For a transfer, retain the bridge change, transferrer, destination, resulting connected-line update and endpoint event.

Do not manufacture a Diversion history to repair a post-answer connected-line display, or replace connected identity merely because the original caller must remain visible. Business policy may require both the original caller and current connected or forwarded party through different fields.

Correct the smallest owner and replay the matrix

Correct only the demonstrated owner: received identity, dialplan field, interception routine, Dial or Queue suppression, endpoint trust or send control, connected-line method, Diversion or History-Info setting, peer template or endpoint display policy. Reload only the affected supported scope and confirm loaded state before replaying.

Retest direct answer, busy and no-answer forward, blind and attended transfer, queue and Local-channel paths, privacy allowed and restricted states, and each relevant trunk or endpoint. Compare channel fields, AMI event if consumed, SIP update, response and display. This workflow is documentation-derived and was not reproduced on a customer or laboratory PBX.

Separate transfer ownership from connected-party updates

When an ARI controller owns REFER, use the transfer-event diagnostic before treating a connected-line or diversion symptom as the transfer cause.

Prove transfer completion before identity repair

The AMI transfer diagnostic keeps event success, target contact, final topology and connected identity distinct.