Sep 01 2020 09:40 PM
Scenario
PSTN Call received on Teams Client, placed call on-hold , resume, click transfer and the call drops.
No changes anywhere, was working until a client drew my attention. Is anyone experiencing similar issue?
Sep 02 2020 02:10 PM
@naimeshmistry I'm going to see if @RealTime_M365 can help - she knows a lot about this topic.
Sep 08 2020 02:33 AM
Can you please see if disabling the New Meeting Experience you are able to resolve the issue?
A drop-down menu appears. Select Settings. The Settings window appears with the General section selected. Click or tap "Turn on new meeting experience (New meetings and calls will open in separate windows.
Uncheck the New Meeting Experience and check if we are able to use the services smoothly.
With Regards,
Satish U
Sep 08 2020 06:42 PM
Tried disabling New Meeting and experience and unfortunately it hasn't resolved the issue.
I disabled the "New Meeting experience" then did a restart of Teams Desktop client.
When I hit the transfer MS seems to think I have hanged up as that what I see "Normal Call Clearing"
Thanks
Naimesh
Sep 08 2020 06:48 PM
Interestingly when I accept the incoming PSTN call on CCX500, I am able to put it on hold > resume > then hit transfer and it works.
I think it seems to be the Teams Desktop client.
Note ( I haven't tried Teams Web Client)
Kind Regards
Naimesh Mistry
Sep 10 2020 10:35 PM
This seems to be the issue with the Latest Teams Client which is causing the issue. I have mine customer also facing the same issue. We have reported the same to Microsoft Engineering on the same.
Since we are on the latest version of the Teams Client we don't see any issues on the same.
With Regard,
Satish U
Sep 29 2020 09:46 PM
@RealTime_M365 are there any further updates from engineering team.
Following are the workarounds
1. It seems I can Pick up PSTN Calls> Hold>Resume > transfer works if I unplug the headset using Teams Desktop Client.
2. Also above with Teams Web client works with headset
I am using Team certified headsets.
Teams version below
Oct 01 2020 12:41 AM
We also experience the same issue within Teams with calls which drops after a second time on hold or transfer.
This is only happening using a headset which is using an USB dongle or USB cable. It does not happen when connecting a headset directly on the Bluetooth of the laptop.
We have tried several brands of headset, but all of them the same issue.
So it has something to do with the Teams client.
Oct 02 2020 11:04 PM
Can you please check in case MusicOnHold Capability is enabled on the policies? In case yes please try to disable the same and test the feature. This should fix it.
Let me know outcome post which we can have future insight from Internal Microsoft Team.
With Regards,
Satish U
Oct 05 2020 02:27 PM - edited Oct 05 2020 02:28 PM
I have had this issue and can reproduce at will. The workaround I have found is to use the web client. While using the web client calls can be placed on hold and then transferred with no issue. Also, this issue has not been seen on the Mac Teams client. It seems to be an issue only affecting. the Windows desktop client.
Oct 07 2020 02:24 PM
Oct 07 2020 05:14 PM
@RealTime_M365 , while I appreciate the work around, I do not want to disable MOH on the policies as its very important feature. I will work with previous work around but would appreciate if you could provide an ETA on the Teams Client used by yourself which has no issues.
Oct 11 2020 11:40 PM
Can you please check it seems that the issue is resolved on the Client for the other customer?
With Regards,
Satish U
Oct 12 2020 12:38 AM
@RealTime_M365 yep seems like this is fixed :).
Nov 15 2020 11:26 PM
Appreciate the workaround. But, is there an actual fix that still leaves MOH enabled.
Our clients would like to have that feature and not leave their customer on siled when they're on hold.
Really appreciate prompt response.
Kind regards,
Chris
Nov 19 2020 12:26 AM
Hi Chris,
Hope you are doing good!!
One option is remove the music on hold file save the overall the Auto-Attendant or Call Queue and then wait for 5-10mins. After 5-10mins edit the Auto-Attendant or Call Queue and upload the same music on-hold file into the Auto-Attendant or Call Queue. This should fix the issue.
With Regards,
Satish U
Nov 19 2020 04:43 PM
We are experiencing this issue with our auto attendant with the Conference mode switch on, we have tired removing the custom music on hold, the Auto attendant then started to transfer calls through to our call queues and then stopped again, we get the lovely message "sorry we cannot connect your call at the moment" and then it drops the call.
Our SBC provider has reviewed the logs on the failed Auto Attendant transfers and Microsoft are not sending back the SIP invite after it transfers, I assume because they are just dropping the call.
No changes have been made on our Auto attendants or call queues so it must be an upgrade gone wrong :(
May 16 2021 04:10 PM
May 16 2021 05:30 PM
SolutionHi @jxace
Our root cause was someone had defined an extra sip port on the hosted SBC trunk in our Direct routing setup
The hosted SBCs were load balancing between 2. Unfortunately though, the fqdn in the contact header means this caused problems with TEAMS.
Our SBC provider disabled the 'bad' port - then all calls were fine in the respect of any ACKs or re-invites etc between TEAMS and the SBC.
Not sure if this helps but good luck
May 17 2021 02:37 PM
@Shane Toal I'm dealing with a much simpler setup with an on prem Cisco CUBE SBC. Have had 4 TAC engineers look over the config, NAT through the firewall is proven correct. I've got a case open with Microsoft now to find out why when they send packets back dealing with REFERs from an Auto Attendant then to a Call Queue they are missing the "user" information. MS support is a joke, btw. Zero communication and we've been dead in the water this entire time.
May 16 2021 05:30 PM
SolutionHi @jxace
Our root cause was someone had defined an extra sip port on the hosted SBC trunk in our Direct routing setup
The hosted SBCs were load balancing between 2. Unfortunately though, the fqdn in the contact header means this caused problems with TEAMS.
Our SBC provider disabled the 'bad' port - then all calls were fine in the respect of any ACKs or re-invites etc between TEAMS and the SBC.
Not sure if this helps but good luck