PSTN call transfers not working

[IBN]

Hello Teams Community, 

Please I need your help on this.

we are having issues transferring incoming PSTN calls that come in through an Auto-attendant and Call queue and are answered by an employee and being transferred to an external PSTN number with the consultive transfer.

Also for more clarification I am not talking about an auto attendant transferring calls?

What I meant is that when a User is answering a call that came in through an auto attendant & Call queue. So this happens when a Teams client User (normal user with licenses) does a consultive transfer to a PSTN number.

The User that answered the call on their Teams client gets an error that the transfer is not working, and they get 2 call screens on hold with both the caller, and the person where the transfer would need to go to.

We can use 2 options when transferring calls. Cold transfer (without consultation) and with consultation (warm transfer). When using the cold transfer option to transfer the caller to the external PSTN number, there is no problem.

They are not having this problem when transferring with internal users. We also own the SBC infrastructure, and we cannot see any error there.

Transfers without consulting, cold transfers, are working. You could see this behaviour at the call with the ID: 8ec345aa-7818-46a3-8172-8d875cf59eff

[#2]

@IBN : we also see this happening since ~1 week.

It is NOT limited to CAlls from AutoAttendants - also external consultative Transfers of calls directly to the (transferring) user fail.
The SBC never receives the REFER, and the Teams-Debug-Log shows an error.

So - it very probably is an error in the Teams--infrastructure.
(See also https://www.reddit.com/r/MicrosoftTeams/comments/syl1fd/sanity_check_consultative_transfer_to_extern... ).

Open a support request and an incident to raise the priority. The more people are affected, the quicker a fix will be deployed ...

[#3]

Thank you for your reply.

I was able to open the link. i saw that it is a bug by the Teams product group and will be fixed within the next 6-8 weeks

Do you also get the same issue

[#4]

@IBN As said, yes, we are seeing the same issue across several tenants and users (not every user in every tenant is affected (yet) ).

But I think MS has not yet realized the importance and/or urgency of a fix for this issue. So every customer that opens another support ticket for this helps to increase priority :)

[#5]

Same Issue here - Workaround is -> cold transfer
_ or to insert the phone number manually when using warm transfer (not realy a usable solution, but at least it works).

[#6]

Got a feedback today from our Provider over here in Switzerland which is providing the SIP Trunk/SBC...

Dear all, after a call with MSFT today, they informed me that there's already a fix developed, but they're currently testing it internally, and after this, it will be released to the rest of the tenants, however they didn't give me any ETA about this.

Dear All, I got an update from MSFT, apparently this fix will be deployed on March 28 (i hope they mentioned 2022).

[#7]

Thanks - great to hear.

Btw, another workaround (apart from cold transfer and entering the number manually) that "worked for us" is doing a separate second call to do the "consult" and then use the "merge calls" function ...