SOLVED

PSTN Call Drops if you do consult transfer - Direct Routing

Copper Contributor

Hi All,

I have an issue very similar to the one discussed in this thread: 

https://techcommunity.microsoft.com/t5/microsoft-teams/pstn-call-drops-if-you-put-the-call-on-hold-t...

started by @naimeshmistry 

We have a very simple setup:

Reception AA->Main Reception Queue->Overflow Queue

PSTN is done via Direct Routing. 2 x Ribbon SBCs 1000 running FW 8.0.3 trunked to Telstra Australia

Around the beginning of March, our receptionist reported that after her Teams client on the reception desktop auto-updated to version 1.4.00.4167 to the next version up the incoming PSTN calls started to drop out during consultative transfer or while putting on hold and resuming off hold. Fortunately, we had a laptop that was stuck with 1.4.00.4167 and she was using that laptop to transfer calls without any issues. Strange enough, we tried to put 1.4.00.4167 back onto her desktop but that did not solve the issue. Since then, we purchased her a completely new desktop and the Teams client is  now 1.4.00.7XXX or 1.4.00.8872 have to check. The issue with dropped consult transfer calls is hit and miss. Sometimes she has no issues all day long, sometimes every incoming call drops out when she tries to do consult transfer. 

Like others mentioned in the original post, we don't have any custom Music on Hold configured in Teams but have one configured on SBCs and this is what gets played back to the person who is on hold. She also has a different headset when she uses the desktop it is a wireless Jabra 900 Pro, when she used her laptop it was Jabra evolve 30 wired one.

Looking at the PSTN log on Teams Admin Portal all calls have 

CallEndReasonLocalUserInitiated

Any help or advice would be much appreciated. It drives us and our customers crazy.

 

 

 

3 Replies
Hi Andrew,

We have had the same issue reported to us by one of our Australian customers on Teams. The test calls that we did seem to point at an issue in Teams connecting the calls, as the SIP legs on the SBCs look completely normal.

Do you have the Direct Routing trunks manually set to use the AU media servers or are they on auto? We have ours set manually to AU and are wondering if this may be the cause.

Did you resolve the issue or is it still existing for you?
best response confirmed by ThereseSolimeno (Microsoft)
Solution

@Gasmanz  Sorry for the late reply, I was on leave and offline last week. Our trunks are set to auto.

The issue went away by itself a few days after my original post and I have not heard any complaints from my receptionist since. 

Very strange. But we are moving our PSTN from Telstra to Vocus, so our Tenant will be talking directly to Vocus managed virtual SBC. So hopefully if the issue comes back it will be easier to troubleshoot. 

@Andrew_Naydonov Thanks for the reply. Seems like I'll have to do some deeper diving now that we have also reverted our trunks to auto but no change in behavior. We'll be reviewing our Oracle SBCs config with the vendor to see if something has changed or if any config elements are causing this.
1 best response

Accepted Solutions
best response confirmed by ThereseSolimeno (Microsoft)
Solution

@Gasmanz  Sorry for the late reply, I was on leave and offline last week. Our trunks are set to auto.

The issue went away by itself a few days after my original post and I have not heard any complaints from my receptionist since. 

Very strange. But we are moving our PSTN from Telstra to Vocus, so our Tenant will be talking directly to Vocus managed virtual SBC. So hopefully if the issue comes back it will be easier to troubleshoot. 

View solution in original post