SOLVED

PSTN Call Drops if you put the call on hold then resume and hit transfer

Copper Contributor

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?

19 Replies

@naimeshmistry   I'm going to see if  @RealTime_M365 can help - she knows a lot about this topic.

Hi @naimeshmistry 

 

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

@RealTime_M365 

 

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

@RealTime_M365

 

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

Hi @naimeshmistry 

 

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

@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

naimeshmistry_0-1601441063262.png

 

@naimeshmistry 

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.

 

 

Hi @naimeshmistry

 

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 

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. 

This exact issue was happening for me. I disabled the MusicOnHold capabiity and the issue no longer persists. This is a nice workaround, but at the cost of hold music.

Also note, that when you disable hold music, it takes several hours for the change to take effect.

@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.

Hi @naimeshmistry 

 

Can you please check it seems that the issue is resolved on the Client for the other customer?

With Regards,

Satish U

@RealTime_M365 

 

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 

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

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 :(  

Shane - I am having the same issue with MS not sending back SIP packets correctly when an outside call comes in through an Auto Attendant then to a Call Queue. Can't transfer or park (says "Transfer failed"). Did you have any luck figuring out this issue?
best response confirmed by ThereseSolimeno (Microsoft)
Solution

Hi @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

@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.

1 best response

Accepted Solutions
best response confirmed by ThereseSolimeno (Microsoft)
Solution

Hi @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

View solution in original post