XDT routing checks the SIP header of an incoming or transferred call for the text XDT <skill name> and, when found, sends the call directly to that skill. No Call Routing rule or IVR configuration is required in CCaaS for this to work — the UC platform or phone system supplies the header value, and CCaaS acts on it automatically.

The Problem XDT Solves

When an agent on a UC phone transfers a call from one skill to another, the resulting SIP header can carry information that matches more than one Call Routing rule. Depending on rule priority, the call can return to the original skill instead of reaching the intended second skill. This issue affects UC phone transfers only — WebRTC users are not affected.

How XDT Routing Works

CCaaS checks the SIP header for the first instance of XDT <skill name> and transfers the call to that skill group, ahead of any configured Call Routing rule. This applies to both inbound calls and calls transferred between skills.

Configuring XDT on the UC Platform

The UC platform must be configured to append XDT <skill name> to the SIP header — the exact method (a group name, prefix, MLHG, or other mechanism) depends on the platform in use. No corresponding rule needs to be created in CCaaS.

Troubleshooting XDT Routing

If a call is not routing to the intended skill, check the following:

• No other occurrence of XDT appears earlier in the header — a caller ID or company name containing "XDT" ahead of the intended value causes CCaaS to skip the intended XDT routing and fall back to any configured Call Routing rule or the default skill group
• The header reads XDT followed by the skill name exactly as defined in CCaaS
• The intended skill is the first instance of XDT in the header — CCaaS always acts on the first instance found. For example, if a call is transferred between skills multiple times and the header ends up containing XDT twice, CCaaS routes to the skill named in the first occurrence, not the most recent one