When forwarding VIP calls to an external mobile number, the original caller’s number (Caller ID) is not displayed; instead, the main number of the SIP trunk (03XXX XXXX-0) is shown.
This issue occurs exclusively when the call is routed through a call queue or call group. If the call is forwarded directly via a standard extension, the CLIP information (the original caller’s number) is transmitted correctly to the destination.
Scenario & Technical Setup
The issue can be reproduced in the following configuration:
1. Incoming Call: A call is received on a DID (e.g., 03XXX XXXX-151).
2. Filtering: A caller ID rule checks whether the incoming number belongs to a stored VIP contact.
3. Routing: If there is a match, the call is forwarded to a queue.
4. Forwarding: Since no agents are logged in (e.g., during on-call duty), the queue’s external forwarding is triggered to a mobile number (e.g., 01XX XXXX-X76).
5. Result: The mobile subscriber receiving the call sees only their own office number instead of the original VIP caller’s number.
Technical Analysis (Wireshark & Provider Feedback)
• SIP Header Analysis: In the outgoing INVITE to the provider, 3CX sets its own trunk main number in the From header.
• Anomaly in Display Info: A combined string (e.g., “Last Name: Test_Hotline”) is transmitted in the From: Display Info field, which, according to the provider, does not represent a legitimate phone number and can interfere with CLIP signaling.
• Version Status: This behavior was validated under 3CX V20 Update 8A using a certified provider template (Easybell).
• Header Configuration: A Diversion header containing the original DID is present in the packet; however, 3CX does not appear to populate the variables for From: User Part and P-Asserted Identity: User Part with the original originator (caller) for queue calls.
• Verified Workaround: When using a Call Flow Script (CFD) instead of the standard hold queue, CLIP transmission works flawlessly.
The issue appears to stem from the specific handling of call queue calls within 3CX V20 when they are routed via CID rules. While extension forwarding preserves the A-number, the call queue overwrites the “From” user part with the default trunk number unless a CFD is used.
This issue occurs exclusively when the call is routed through a call queue or call group. If the call is forwarded directly via a standard extension, the CLIP information (the original caller’s number) is transmitted correctly to the destination.
Scenario & Technical Setup
The issue can be reproduced in the following configuration:
1. Incoming Call: A call is received on a DID (e.g., 03XXX XXXX-151).
2. Filtering: A caller ID rule checks whether the incoming number belongs to a stored VIP contact.
3. Routing: If there is a match, the call is forwarded to a queue.
4. Forwarding: Since no agents are logged in (e.g., during on-call duty), the queue’s external forwarding is triggered to a mobile number (e.g., 01XX XXXX-X76).
5. Result: The mobile subscriber receiving the call sees only their own office number instead of the original VIP caller’s number.
Technical Analysis (Wireshark & Provider Feedback)
• SIP Header Analysis: In the outgoing INVITE to the provider, 3CX sets its own trunk main number in the From header.
• Anomaly in Display Info: A combined string (e.g., “Last Name: Test_Hotline”) is transmitted in the From: Display Info field, which, according to the provider, does not represent a legitimate phone number and can interfere with CLIP signaling.
• Version Status: This behavior was validated under 3CX V20 Update 8A using a certified provider template (Easybell).
• Header Configuration: A Diversion header containing the original DID is present in the packet; however, 3CX does not appear to populate the variables for From: User Part and P-Asserted Identity: User Part with the original originator (caller) for queue calls.
• Verified Workaround: When using a Call Flow Script (CFD) instead of the standard hold queue, CLIP transmission works flawlessly.
The issue appears to stem from the specific handling of call queue calls within 3CX V20 when they are routed via CID rules. While extension forwarding preserves the A-number, the call queue overwrites the “From” user part with the default trunk number unless a CFD is used.
