Unexpected caller ID during transfers can confuse staff even when the call connects and audio works. A receptionist may see the outside caller, while the next extension sees the receptionist. An external destination might instead see the company’s main number or an anonymous label.
These outcomes do not always mean information vanished. A transfer creates or reconnects call legs, and each leg can carry different identity information. The useful question is: where did the identity first differ from the intended result?
Define Which Caller Identity Should Appear
Start with the display requirement, not a setting change. Record whose screen shows the problem and when it changes. Distinguish the caller’s number from the caller’s name; they may come from different sources.
- Should the receiving extension see the outside caller or the transferring employee?
- Does the display change while ringing, after answer, or after transfer completion?
- Can the original caller see a new connected party?
- Is the issue limited to internal transfers, external transfers, or both?
- Does the number disappear, or does only the name change?
A blind transfer sends the caller onward without a consultation. An attended transfer includes a conversation with the destination first. During that consultation, seeing the transferring employee’s identity can be correct.
This guide concerns identity on completed transfers. If completion itself fails, use the separate attended transfer failure workflow.
Map Caller ID Across the Transfer’s Call Legs
A PBX, or business phone system, often maintains separate signaling relationships with each participant. SIP, the Session Initiation Protocol, carries call setup and control messages. A SIP call leg is one part of that larger conversation.
For a typical attended transfer, map these checkpoints:
- The provider delivers the outside call to the PBX.
- Next, the PBX rings the receptionist’s phone.
- The receptionist starts a consultation with the receiving extension.
- After consultation, the PBX connects the outside caller to that extension.
An external transfer adds a provider-facing outbound leg. That leg introduces another identity policy, even when the original inbound identity was correct.
Track each leg separately. A PBX may use different SIP Call-ID values for different legs. Correlate them through timestamps, participants, and PBX channel or linked-call identifiers.
Transfer designs also vary. SIP REFER requests another party to initiate a request, commonly a new call. It does not guarantee a particular caller display. Our transfer architecture comparison explains who controls those relationships.
Read From and P-Asserted-Identity Together
SIP headers are named fields inside signaling messages. Several fields describe identity, but they serve different purposes. No single field universally controls every phone screen.
From Describes the Request’s Logical Initiator
The From header identifies the logical initiator of a SIP request. It can contain a display name and an address. Its address user portion may resemble a telephone number, extension, or account name.
On a consultation leg, From may identify the transferring extension rather than the outside caller. That alone does not prove an error. Compare it with the transfer stage and the PBX’s intended behavior.
A provider may also require an account identity in From. Do not replace it with an arbitrary outside number without checking the trunk requirements.
P-Asserted-Identity Depends on a Trust Relationship
P-Asserted-Identity, often called PAI, conveys an identity asserted within a trusted SIP network. A PBX or provider may use it separately from From.
PAI is not proof that any sender owns the number it supplies. Trust rules determine whether a system accepts, rewrites, forwards, or removes it. Never enable broad identity trust for unknown SIP sources merely to restore a display.
Inspect privacy indicators alongside both fields. An anonymous From value can coexist with identity information inside a trusted network. Preserving a legitimate privacy request matters more than displaying a hidden number.
Separate Redirect History From Connected Line Updates
Redirect history explains how a call reached its destination. Connected line information describes the party now connected. Neither concept is interchangeable with the original caller.
Diversion and History-Info Explain the Route
Diversion commonly carries information about a redirecting party and the reason for redirection. History-Info can record request retargeting history across multiple destinations.
These headers do not automatically replace caller identity. A transfer may not produce either header, depending on its implementation. Providers also differ in which redirect information they accept or require.
For an external transfer, a provider might require an authorized business number plus redirect information. Copying the original caller into every identity field can violate that policy.
Connected Line Updates Can Change the Screen After Answer
A PBX can send connected line updates when the connected party changes. Depending on endpoint support, SIP signaling may carry these updates in responses, re-INVITE messages, or UPDATE requests.
A re-INVITE revises an existing SIP session. UPDATE can revise session information without starting a new dialog. Their presence alone does not prove an identity update occurred.
Inspect the actual identity fields and their direction. For an attended transfer, the destination may initially show the receptionist and later show the outside caller. A missing, blocked, or ignored update can leave the consultation identity on screen.
Capture One Controlled Transfer and Compare Checkpoints
Use consenting participants and a test destination you control. Schedule the test when brief logging will not burden production. SIP traces can expose phone numbers, internal addresses, and authentication material.
- Record the baseline. Note the incoming number, displayed name, extensions, timestamp, and time zone.
- Photograph or record display changes. Capture ringing, consultation, answer, and completion without exposing unrelated calls.
- Collect relevant signaling. Use approved PBX logging or a narrowly scoped capture.
- Build a leg-by-leg timeline. Compare From, PAI, privacy, redirect history, and later identity updates.
- Mark the first unexpected value. Identify which system sent it and which system received it.
Encrypted SIP may prevent a network capture from revealing headers. Use authorized endpoint or PBX diagnostics instead of weakening transport security.
For caller ID during transfers, this comparison is more useful than collecting every packet on the network. Stop temporary logging afterward, restrict access, and redact evidence before sharing it.
Use the First Difference to Choose the Fix
Compare signaling with the visible result before changing policy. These patterns narrow the investigation:
- Inbound identity is already absent: Investigate provider delivery or privacy before transfer handling.
- PBX receives the caller but sends the receptionist: Inspect channel identity, transfer logic, and connected line policy.
- Correct identity reaches the phone but not its display: Check endpoint identity preferences, firmware behavior, and local contacts.
- Identity changes only on external transfers: Compare outbound trunk policy and provider acceptance rules.
- Only the name differs: Check phone directories and provider name lookup separately from number signaling.
If the PBX sends the intended number upstream, request a provider trace. Include the test time, destination, and relevant call identifiers. The receiving carrier or handset may apply its own display rules.
A company number on an external transfer can be intentional. Providers may restrict presented numbers to authorized identities. Header rewriting alone cannot guarantee original-caller presentation across the public telephone network.
Review PBX Policy Without Weakening Identity Controls
In Asterisk-based systems, inspect caller identity, connected line handling, redirect information, and endpoint trust as separate controls. Consult the official Asterisk documentation for your installed channel driver and release.
FreePBX settings and generated behavior vary by release and module. Check the supported interface before editing configuration files. Manual edits to generated files may disappear during later changes.
- Save the current configuration and define a rollback step.
- Change only the control supported by the trace evidence.
- Retest blind and attended transfers to internal and external destinations.
- Confirm that anonymous calls still follow the required privacy policy.
- Verify names, numbers, consultation displays, and final connected displays.
Successful handling of caller ID during transfers means the right identity appears at the right stage. It does not mean every participant always sees the original number.
Professional remote assistance may help when PBX behavior, endpoint displays, and carrier policy disagree. Tech Rescue Ops LLC provides remote VoIP and PBX support to review evidence and plan targeted changes.