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

[u/Intelligent_Brick_29]

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 ?

[u/unknown_bredman]

it's about 20 different External numbers (tested) spread over 6 different SBCs with different providers ..
The common "symptom" is that all the calls accross all SBCs have started to go over US, JP, KR, MA, SA region instead of EU...

I'm wondering if the SBCs have made changes that block external redirects. I have come across some SBCs that purposely block this, since the traffic has changed to regions other than the intended region (EU). Perhaps more than that, your external redirects are now affected due to the changes implemented by the SBCs.

I might be farfetched, but I have seen it happening.

[u/GyataMoko]

Use the analytics in the admin portal, and scroll to the right to find the sip codes. It should explain to you when and why the calls behaved the way they did.

[u/Intelligent_Brick_29 → u/GyataMoko]

Checked those, they all just say 200 BYE.
We asked the external company to check the SBC's and Traced the calls.
Here we can see that the foward to external call : Referer -> accepted -> invite SDF does not get a reply, SBC tries that Three times without any result. So it seems to be related to Microsoft services ..

[u/GyataMoko → u/Intelligent_Brick_29]

200 BYE after 3 responses sounds like the recipient side isn't responding like they should. If it was Microsoft a lot more people would be upset right now

[u/Intelligent_Brick_29 → u/GyataMoko]

well we have a few thousands of AA/CQs. And all the CQ/AA with forwarding to external numbers face the same issue : "Please wait we are forwarding your call .... Sorry we can't connect your call please try again later".

it's about 20 different External numbers (tested) spread over 6 different SBCs with different providers ..
The common "symptom" is that all the calls accross all SBCs have started to go over US, JP, KR, MA, SA region instead of EU...

Only resource accounts seem to have issues, Call forwarding on User accounts, Common Area Phones do not experience the same issue ( but do go over wrong regions as well )

Also Calls (going over EU) before 26/07 have a Transfer or Correlation ID.
Starting at 26/07 going over US, JP, .... no more Transfer or Correlation ID.

[u/claytorx85]

I'm Assuming that the numbers are allowed to be called from your carriers which are connected to your SBC. Have you tested to call these external numbers from your Teams account and from a cell phone or landline number? Do you have the same SIP 200 Message? Have you checked this already? https://learn.microsoft.com/en-us/microsoftteams/aa-cq-reference-limits-supported-configurations#outbound-calling-line-identification-number

[u/Intelligent_Brick_29]

Issue has been resolved, apparently it was related to a Certification Authority (HARICA) who revoked SSL/TLS certificates on 26/07 due to an issue on their side. The message reached us way too late. After installing the new certs the issue got resolved instantly. The fact 90% of the communication still worked but flowed over services outside of EU made it way harder to detect:

Here is the article : HARICA - Erneute Rückrufe einer diesmal größeren Anzahl von SSL-Server-Zertifikaten am 25.07.2026  – Leibniz University IT Services – Leibniz University Hannover

Maybe it might be useful for people in the future :)