SOLVED

Incoming Call Queue Calls - Transfer Failed

Copper Contributor

We use teams calling (Co-Existence set to Teams Only) for our calling center, have not had any issues until about 4-5 months ago when we lost the ability to transfer calls when customers dial in to our call queue. This is the call flow:

 

End users call into our phone number (either the toll free or local number) > greeted with the call queue/available options > user selects applicable options and is routed to the applicable team. A Technician answers the call via the desktop client. If the technician needs to transfer to an external number (IE an employees cell phone), the call fails and the end user is hung up on. At this point I've escalated and escalated internally with Microsoft to no avail. After troubleshooting we noticed that through the mobile application, using the exact same call in process, we can transfer to external phone numbers; this is the same case for the web app. Both of these options are less than ideal. I am just curious if anyone has witnessed these same issues, and what was done to resolve them? Microsoft support has not been able to help at all and our ticket is 2-3 months stale at this point with no progress besides a "we are still working on this but have no idea" daily email.

11 Replies

Is there anyway to get a response to this?

Any update on this? we have exactly the same situation
Not a single response on this forum, nor through our ongoing support ticket, which is a few months old at this point. have provided logging in every which way, shown every single example and create the issue every time, no assistance what so ever.

@ThomasT4  we're having the same issue on both CallQueues and AutoAttendant. MS is not identifying the problem, if you get any answer/solution please let us know.

 

Thx,

Emilio

Anyone get any answers on this? Call Queues call transfers fail if the person select the work number. If they just select the person then hit transfer the call transfer works... Its been working for the last several months just stopped today.

@Michael Seifert maybe this is a stupid question, but have you checked the OnlineRoutingPolicy?  I am assuming if you select the person's name it is a Teams to Teams call, but selecting the mobile number requires a routing policy that will allow the calls to external numbers or mobile numbers.

@ABWCCIt is very odd, manually typing an external number will transfer the call, selecting a person and doing the drop down and trying to transfer to work number or cell number the transfer fails. In AD our numbers are formatted +15551234567.   Teams to Teams call then transfer to cell number or ad number works, so the issue only appears if the call came into a call queue.

@Michael Seifert 

 

This is the exact issue we are having. We can have a call come in directly to our teams numbers, and can transfer successfully in any way possible. The call makes it through the transfer via external number, internal number, directly through teams, etc.

 

It is when the call comes in through a call queue that the call can not be transferred. we receive a "transfer failed" error. it's beyond frustrating and my ticket open with Microsoft is still being worked since January and this thread is only now getting traction.

best response confirmed by ThereseSolimeno (Microsoft)
Solution
@ThomasT4 I just heard from microsoft support. They asked me to try the web client. Guess what, the web client DOES work. Evidently there must be an issue with the desktop client.

@ThomasT4 

In our scenario we had to configure REFER handling on the gateways - UCGeek blog post 

As well as "Conferencing mode" was causing the problems in the call queue. Our SBC firmware needed to be upgraded to support that feature

image.png

@Michael Seifert Could you solve the problem back then? We are encountering the same dilemma currently.

1 best response

Accepted Solutions
best response confirmed by ThereseSolimeno (Microsoft)
Solution
@ThomasT4 I just heard from microsoft support. They asked me to try the web client. Guess what, the web client DOES work. Evidently there must be an issue with the desktop client.

View solution in original post