Forum Discussion

BM001's avatar
BM001
Copper Contributor
Jul 27, 2026

Auto Attendant & Call Queue Call forwarding to external numbers failing.

Hi all,

Since this weekend users accross our org. have been noticing that AA/CQ that forward Calls to external numbers FAIL. This was not the case last week.

Flow example :
User dials number of AA, this AA has a menu which has Internal and external numbers.
Internal numbers -> no problem.
Externa numbers -> message (new never heard this): "Please Hold while we forward your call, .... Sorry we could not forward your call at this time, try again later".

On user level we are not experiencing this issue when I redirect my calls from work number to external number there is no issue.

What is very strange in this entire scenario is that we are EU bases, the resource accounts "Usage location" is on the proper country in EU.
But in the Microsoft PSTN USAGE logs we see that the "Azure region for Media" is USSC, USEA, USWE, JPWE, JPEA, MAWE, KRCE where it should be EUWE, FRCE and EUNO ... But No Fail Codes, just Bye ...

The dates hold up with the issue... before 26/07 everything passed over EU Region.
After 26/07 everything passes over US, KR, MA, JP ...

Anyone else having this issue ? Related to the new AI routing implementation gone bad ?

1 Reply

  • Your tests isolate this to the Auto Attendant/Call Queue voice-application path: internal destinations and user-level external forwarding work, while AA/CQ external transfers fail from 26 July. The changed Azure media-region values are evidence, but they do not alone prove a routing fault or AI-related change.

     

    First, check Microsoft 365 admin center > Health > Service health for a Teams Phone incident and issue history. Run the Teams Auto Attendant diagnostic for each resource account. Confirm each account still has its Teams Phone Resource Account license, service number, and usage location. Reproduce failed AA and CQ calls, then export their PSTN usage records and note UTC time and Call ID. If you use Direct Routing, include the SIP call flow from that report. If service health is clear and diagnostics pass, report the issue or open a Microsoft support case with those records and the first observed failure time.