Issues with call transfers - Microsoft Teams

Publisher

Microsoft

URL

https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/issues-with-call-transfers

Published

2026-08-31

Updated

unknown

Accessed

2026-09-25

HTTP status

200

License

Microsoft Learn; CC BY 4.0 for docs content where stated; no-redistribution; short excerpts and locators only

Source notes citing this source

• For Direct Routing, if an auto attendant can transfer to an internal user or bot but not to an external PSTN number, Microsoft says this may indicate missing or incorrect licensing on the auto attendant. in context
• Blind-transfer behaviour for Direct Routing changed in June 2026 (Message center MC1296872): Microsoft now ends the call immediately after the SBC accepts the transfer, without waiting for the final transfer result. in context
• For consultative transfers over Direct Routing, calls drop early if the SIP proxy does not get a 202 Accepted and NOTIFY progress from the SBC or the SBC sends BYE too early; the SBC must send 202 and NOTIFY so the proxy can end the original call after a NOTIFY carrying 200 OK. in context
• Teams can transfer a Direct Routing call by SIP REFER, by SIP INVITE with a Replaces header, or through internal Teams infrastructure, in that order of preference; the INVITE-with-Replaces method is mostly used for call queue responses. in context
• If the SBC never receives a SIP REFER, Microsoft advises allowing incoming connections from any Microsoft signaling IP address, because the REFER can arrive over a new TLS connection from a different address than earlier call legs. in context
• When the Microsoft SIP proxy sends a REFER, the SBC must send the new INVITE back to the SIP proxy, not to the PSTN, even for transfers to an external number, copying the Refer-To and Referred-By strings unchanged. in context
• Firewall and SBC settings must accept connections from any Microsoft signaling IP address because a REFER can arrive on a new TLS connection from a different address. in context
• Since a June 2026 change (Message Center MC1296872), Microsoft ends a blind-transferred Direct Routing call as soon as the SBC accepts the REFER, without waiting for the transfer result. in context
• For consultative transfers the SBC must return 202 Accepted and NOTIFY progress to the REFER; the proxy ends the original call only after a NOTIFY carrying 200 OK. in context
• On a Teams REFER the SBC must send the new INVITE back to the Microsoft SIP proxy, with the Request-URI set to the Refer-To string and the Referred-By header copied unchanged, even when the target is an external PSTN number. in context
• Teams initiates Direct Routing transfers by SIP REFER first, then INVITE with Replaces, then an internal method invisible to the SBC if neither is supported. in context
• Microsoft's Direct Routing call-transfer troubleshooting guidance does not apply to Calling Plan or Operator Connect deployments. in context

Cite this source record

APA

WarmTransfer. (2026, August 31). Issues with call transfers - Microsoft Teams. WarmTransfer. https://warmtransfer.net/knowledge/sources/ms-learn-dr-call-transfer-issues

BibTeX

@misc{warmtransfer-ms-learn-dr-call-transfer-issues,
  title  = {Issues with call transfers - Microsoft Teams},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/sources/ms-learn-dr-call-transfer-issues},
  note   = {Microsoft, accessed 2026-09-25}
}