Troubleshoot Webex Calling Queue-to-Queue Transfer Caller ID Issue

Issue

In Webex Calling, when an external PSTN call enters through an Auto Attendant, it is answered by an agent in one Call Queue, and then transferred to another Call Queue. The original PSTN caller ID is not preserved. Agents in the destination Call Queue see the transferring agents name and extension instead of the external callers information for both blind and consultative transfers.

Specifically, the receiving agents endpoint displays the transferring agents identity such as their name "Matthew Jones" and extension "6032." Instead of the original PSTN callers calling name and calling number. The original callers identity is not visible on the receiving agents display in any transfer method tested.

Testing confirmed this behavior occurs with:

• Blind/unattended transfer (press transfer, dial extension, hang up)

• Consultative/attended transfer (press transfer, dial extension, wait for answer, complete)

The supplementary SIP headers (Diversion, History-Info) appear to carry the original calling party information through the transfer leg, but the destination endpoints display reads from the From/Calling Line ID field, which contains the transferring agents identity rather than the original PSTN caller.

Environment

• Webex Calling platform

• Call Queue-to-Call Queue transfer scenario

• PSTN calls routed through Auto Attendant

• Both blind and consultative transfer methods

• Multiple agent endpoints (IP phones and Webex App)

Resolution

Analysis of SIP signaling and call flow revealed this behavior is currently expected in Webex Calling for Call Queue-to-Call Queue transfers. The investigation showed:

Technical Analysis Findings

SIP signaling analysis of INVITE messages sent to the destination endpoint showed:

From:"JONES MATTHEW"<sip:+15736298032@144.196.33.67;user=phone>;tag=1264046368-1777922774622-
Diversion:"Hannibal Board of Public Works"<sip:+15732218050@10.71.101.45;user=phone>;reason=deflection;counter=1

The caller ID sent to both the Webex App and the Device shows "Matthew Jones" with extension "6032", while the original PSTN caller information (+15736298032) is preserved only in supplementary headers. The endpoints display logic reads from the From/Calling Line ID field rather than the Diversion or History-Info headers.

Transfer Method Behavior

Backend log analysis revealed transfers are initiated via XSI-events rather than REFER signaling from an IP phone. For both transfer methods:

• Consultative Transfers: Expected to display the transferring agents caller ID by design

• Blind Transfers: Display the transferring agents identity in Call Queue-to-Call Queue scenarios

Configuration Options Tested

These configuration changes were tested with no effect on the behavior:

• Changed Connected Line Identity Privacy for Redirected Calls setting from "Redirecting identity for external calls" to "Redirecting identity for all calls"

• Verified no user-level, queue-level, or location-level settings in Webex Control Hub alter this behavior

Current Status and Workaround

No documented configuration exists to preserve the original PSTN caller ID for Call Queue-to-Call Queue transfer flows. This behavior is currently considered expected for Webex Calling. A feature enhancement request exists to display full caller information.

Cause

This is expected platform behavior in Webex Calling for internal Call Queue-to-Call Queue transfers. The destination endpoints display reads from the From/Calling Line ID field, which contains the transferring agents identity rather than the original PSTN caller information. While the original calling party information is preserved in supplementary SIP headers (Diversion, History-Info), the endpoint display logic does not utilize these headers for caller identification in queue-to-queue transfer scenarios.

Related Content

• Feature Enhancement Request - Display Full Caller Information

• Configure Features for Cisco IP 8800 Series Phone - Transfer Methods

• Cisco Technical Support & Downloads

Revision History

Revision	Publish Date	Comments
1.0	10-Nov-2026	Initial Release