We’ve set up the Microsoft Teams Direct Routing integration with Genesys Cloud.
When a customer calls a native Teams user, and that Teams user transfers the call into a Genesys Cloud queue via the SIP tie-trunk, the agent in Genesys Cloud doesn’t see the customer’s phone number. Instead, the ANI displays our main MS Teams SBC trunk number. I ran a PCAP trace on the Edge server, and the correct customer phone number is present in the P-Asserted-Identity (PAI) header sent by Teams. However, Genesys Cloud seems to be ignoring it and reading the From header instead. How can I force Genesys Cloud to prioritize the PAI header for caller ID on this specific trunk?
We just deployed this for 800 agents in Japan and had the exact same headache!
Go to your SIP Trunk settings in Genesys Cloud, under ‘Identity’. Look for the setting called ‘Prioritized Caller ID Headers’. By default, it’s usually set to From, P-Asserted-Identity, Remote-Party-ID. You need to reorder that list so that P-Asserted-Identity is at the very top. Once you do that, the Edge will check the PAI header first, grab the customer’s E.164 number, and the agent’s desktop will populate correctly!
One quick warning for the WFM and scheduling side if you make that change:
When you flip the Caller ID prioritization, it affects your analytics reporting too. If you pull a ‘Conversation Detail’ report, the ani dimension will now correctly show the customer’s number instead of the Teams trunk number. This is great, but make sure your historical reports don’t break if you were filtering specifically by the Teams trunk number to track transferred volumes. You might need to use dnis or purpose flags instead to identify those routed calls now.
Thanks for the heads-up, everyone. The header reordering trick worked like a charm for the ANI visibility.
I went into the SIP Trunk configuration, switched the Prioritized Caller ID Headers to P-Asserted-Identity, From, Remote-Party-ID, and immediately tested a transfer from Teams. The Edge now correctly parses the customer’s E.164 number instead of masking it with the SBC trunk ID.
However, as a side note for anyone dealing with email routing or omnichannel contexts: while this fixes the voice ANI, keep an eye on your interaction metadata if you’re correlating voice with email. We had a similar issue where the ANI field in the Genesys Cloud API responses for transferred calls was still showing the trunk number in some legacy report views until the cache cleared.
For those managing HTML templates or canned responses tied to these interactions, ensure your dynamic fields (like {{conversation.ani}}) are pulling from the updated P-Asserted-Identity source. If you have custom signature stripping rules or auto-reply triggers based on caller ID, you might need to update your regex patterns to account for the new format.
Also, double-check your Edge logs. If you see 403 Forbidden or header rejection errors after this change, it might be because the Teams SBC is not properly asserting the identity in the PAI header for all call flows. In that case, you might need to adjust the SBC configuration to ensure P-Asserted-Identity is populated before the call hits the Genesys Edge.
Big thanks for the quick fix. Saved me hours of PCAP analysis.