Queue forwarding to Vapi sends main trunk caller ID on V20 U10, but preserves original caller ID on U9

[farman khan]

Title: Queue forwarding to Vapi sends main trunk caller ID on V20 U10, but preserves original caller ID on U9

Hello 3CX Community,

I’m troubleshooting a caller ID issue when a queue forwards an unanswered incoming call to an external Vapi AI assistant number.

The call reaches Vapi successfully, but Vapi’s call log displays the main trunk number instead of the original caller’s number.

Call flow

1. An external caller, with a number ending 7317, calls our DID ending 8153.
2. The call enters queue 80029 — TEST QUE.
3. If unanswered, the queue uses Forward to Outside Number to call the Vapi number ending 4788.
4. Vapi answers, but displays the main trunk number ending 9552 as the customer/caller.

The expected result is for Vapi to display the original caller’s number ending 7317, with this working dynamically for every caller.

Comparison between two PBX systems

I tested the same forwarding scenario on two systems:

Setting	Working system	Affected system
PBX	3ctel.3cx.ca	3ctel1.my3cx.ca
Version	V20 Update 9, Build 995	V20 Update 10, Build 1621
Edition	PRO	AI
Hosting	Hosted by 3CX	Self Hosted
Vapi caller ID result	Original caller number	Main trunk number

I compared the visible trunk, queue, and outbound rule settings, and they appear equivalent. However, the results differ.

On the affected system, the forwarding call report shows that the external call uses the “Outbound Calls voip.ms” rule and VoIP.MS trunk. The incoming DID belongs to a separate Twilio trunk, and the number displayed in Vapi matches that incoming trunk’s main number.

Could someone help clarify the following?

• Is there a known caller ID forwarding issue or behavior change in Update 10 Build 1621?
• Which SIP fields should carry OriginatorCallerID for this queue forwarding scenario: From, Remote-Party-ID, or P-Asserted-Identity?
• Could the saved provider template and the active trunk mappings differ even when the visible settings match?
• Which logs or SIP capture details would establish whether 3CX sends the main trunk number or the provider replaces the original caller ID afterward?

I have attached the queue configuration, call report, Vapi call log, trunk details, and dashboards showing both versions. I can provide the provider templates and matching test captures if needed.

Any guidance on the correct configuration or further troubleshooting would be appreciated. Thank you.

 

[BrunoI_3CX]

Hello @farman khan

Since the behavior differs between the two systems, could you please confirm whether both systems are using the same SIP Trunk provider and whether they are configured using the default system template or a custom/modified template?

That said, please note that presenting the original Caller ID when forwarding an incoming call to an external number depends on the outbound SIP trunk configuration and whether the provider supports CLIP No Screening.

If CLIP No Screening is supported by your provider, please also clarify with them which SIP header they require the original Caller ID to be presented on outbound calls.

Additionally, does the outbound rule used for forwarding the call have an explicit Outbound Caller ID configured?

Please advise.

 

[farman khan]

Hello,

Thank you for your response. We use Twilio, VoIP.ms, and Telnyx across our PBX systems. I have attached the dashboards, SIP trunk inventories, and outbound rule for comparison.

We are experiencing inconsistent caller ID behavior when an incoming call is forwarded from a queue to our external Vapi AI assistant number.

PBX	Version	Hosting / edition	Observed forwarding result
3ctel.3cx.ca	V20 U9, Build 995	Hosted by 3CX / PRO	Original caller ID in the successful test
ampvoip.my3cx.ca	V20 U9, Build 995	Hosted by 3CX / PRO	Main trunk number
soundinsurance.my3cx.ca	V20 U9, Build 995	Hosted by 3CX / PRO	Main trunk number
3ctel1.my3cx.ca	V20 U10, Build 1621	Self Hosted / AI	Main trunk number

Additional tests

• When I call from 3ctel1.my3cx.ca to 3ctel.3cx.ca, and the receiving queue forwards the call to Vapi, Vapi displays the original caller ID correctly.
• When I make calls from the other systems, Vapi displays a main trunk number instead of the original caller ID.
• When I reverse the test and call from 3ctel.3cx.ca to the other systems, and their receiving queues forward the call to Vapi, Vapi again displays a main trunk number instead of the original caller ID.

The calls connect successfully in all these scenarios. The issue concerns the caller identity presented on the forwarded leg. We need Vapi to display the original caller’s number dynamically for every forwarded call.

The issue also occurs on systems running the same version, edition, and hosting type as the working system.

Regarding your questions

• The inventories show built-in voipms.pv.xml, twilio.pv.xml, and telnyx.pv.xml templates. Some trunks use generic templates; Regiment Telnyx uses GenericVoIPProvider.pv.xml, whereas Telnyx LLC uses telnyx.pv.xml.
• In the attached “Outbound Calls voip.ms” rule, Outbound Caller ID is blank on all three visible routes. Route 1 uses VoIP.MS, and routes 2 and 3 use Regiment VoipMS.
• The previously supplied failing call report confirms forwarding through “Outbound Calls voip.ms” → VoIP.MS, while the incoming DID belongs to a Twilio trunk.
• We have not yet confirmed the required caller identity header and CLIP No Screening requirements with each provider.

One failing example is:

Caller ending 7317 → DID ending 8153 → queue 80029 → Vapi number ending 4788.

Vapi displays main trunk number 9552, although the expected caller ID is the number ending 7317.

Could you please advise how to compare the active inbound and outbound caller ID mappings on these systems, particularly From, P-Preferred-Identity, P-Asserted-Identity, Remote-Party-ID, and Diversion?

Please confirm which matching logs or SIP captures you need from the successful and failing tests, and whether a trunk’s active mappings can differ from its displayed built-in template.

Thank you for your assistance.

 

[Alphabetic]

You would need to export your sip providers and review the XML

 

[farman khan]

Hello,

Thank you. Following your recommendation, we exported and compared 15 provider-template XML files.

The comparison shows:

• All five VoIP.ms exports are byte-for-byte identical.
• All five Twilio exports are byte-for-byte identical.
• Both GenericVoIPProvider exports are byte-for-byte identical.
• Twilio Auto-setup has the same caller-ID mappings as the regular Twilio template.

The relevant outbound mappings are:

• VoIP.ms: FromUserPart uses $AuthID; RemotePartyIDCallingPartyUserPart uses $OutboundCallerId.
• Twilio: FromUserPart, RemotePartyIDCallingPartyUserPart and P-AssertedIdentityUserPart all use $OutboundCallerId.
• Generic templates: FromUserPart and RemotePartyIDCallingPartyUserPart use $OutboundCallerId.
• Dedicated Telnyx: FromUserPart uses $EnforcedOriginatorCallerId.

Our inventory also shows “Regiment Telnyx” using GenericVoIPProvider.pv.xml, while “Telnyx LLC” uses telnyx.pv.xml.

Only 3ctel.3cx.ca preserves the original caller ID. ampvoip.my3cx.ca, soundinsurance.my3cx.ca and 3ctel1.my3cx.ca display a main trunk number in Vapi. Some affected systems have the same U9 build, hosting and edition as the working system.

Example: caller +15. . . 7317 → Twilio DID +16. . . 8153 → queue 80029 → Vapi +128. . . 788. Vapi displays +16. . . . 9552.

The previously supplied failing call report identifies “Outbound Calls voip.ms” → VoIP.MS as the forwarding route. The visible outbound-rule Caller ID fields are blank.

When 3ctel1 calls 3ctel and 3ctel forwards to Vapi, the original caller ID is preserved. When 3ctel calls an affected PBX and that PBX forwards to Vapi, a main trunk number appears instead.

Could you please confirm:

1. How can we inspect or export each trunk’s active caller-ID mappings, rather than only its provider-template defaults?
2. Could trunk/template synchronization differences explain the results despite identical template exports?
3. For the VoIP.ms route, should we retain FromUserPart as $AuthID and change RemotePartyIDCallingPartyUserPart to $OriginatorCallerId?
4. Which incoming and outgoing SIP captures do you need, including From, RPID, PAI, PPI and Diversion, to identify where the caller number changes?

We have not yet applied the proposed custom-template change or confirmed the provider-side forwarding requirements.

#Important: What's the thing which make the 3ctel.3cx system able to forward the orignall caller id, and whats the things which stop the other system to forward the orignal caller id the vapi.

Thank you.

 

[leejor]

Have you looked at the 3CX Activity Log (Verbose) to confirm what Caller ID is actually being sent to the provider?