question

Mystryman007 avatar image
0 Votes"
Mystryman007 asked JimmyYang-MSFT commented

Skype for Business server 2019 Odd Call Drops

Issue: PSTN callers experience dropped calls from Meetings, Response groups and transfers.

Environment:
2 Skype for Business Pools - geographically located in different cities.
Pool A is the primary active pool
Pool B is the secondary pool

AudioCodes SBCs running with F5 hardware Load balancing.

When the issues occurs:
when calls travers pool B mediation and then pass through to Pool A FE.

Example 1:
Caller dials Central Number
Caller arrives in Site B SBC
Caller is passed to Mediation pool B
Caller is connected to SfB Front end on Pool A
Caller is handled through a response group and placed into Queue.
Call is answered by first person and then transferred within SfB Pool A
Call is answered by Second person and connected with the Caller.
Approx. 30 seconds after being connected, the caller will be disconnected

Example 2:
Caller dials into a SfB meeting via PSTN, but connects through Pool B SBC
Call is passed from Pool B Mediation pool to Pool A Front End
Caller will remain connected to the meeting for exactly 15 minutes and then be dropped(their chat and screen share will remain in tact)

Hypothesis is that traffic being routed through Pool B Mediation is creating a failure when the call is connected to Pool A Topology.

Questions:
1. Should we change the routing in the SBC to connect directly to Pool A, unless it is unavailable and then direct to Pool B?
2. Is there another reason for the drop? Mediation configuration is incorrect?

NOTE: two specific errors occur and only occur when calls pass through pool B: 52112 and 10408



office-skype-business-server-administration
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

JimmyYang-MSFT avatar image
0 Votes"
JimmyYang-MSFT answered JimmyYang-MSFT edited

Hi @Mystryman007,

Does this issue happened in your internal or external network?

Our environment has not done such a deployment due to the limitation. But According to your description, this issue happened when call passed to Mediation pool B. As you said, you could try to change the routing in the SBC directly to Pool A to see if this issue can be fixed.

If this issue occurs from external network, we also recommend you check your proxy server’s time out setting and change it to 600 seconds. For more details, you can refer to:

https://social.technet.microsoft.com/Forums/en-US/de2d45b9-8d73-4e1e-adf9-27c7bfb11306/skype-call-dropping-after-3039-seconds?forum=sfbfr

Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please make sure that you completely understand the risk before retrieving any suggestions from the above link.


If the response is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

· 4
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thank you for the link and details

Proxy time was already set to 600.

We implemented a change within our SBC that we are going to be tracking for the next day or so.

MS has also recommend backing out an initial change they suggested on the TrunkConfig. This will return the RTCPActiveCalls, RTCPCallsOnHold and SessionTimer values to True.

I will update with more information and details after these settings are in place. I should have details to share 5/24/2021

0 Votes 0 ·

Hi @Mystryman007

It has been a while, how is everything going?

If you have any update about this issue, please feel free to post back.

0 Votes 0 ·

We made the changes to the SBC, unfortunately, the drops are still present. The unfortunate thing now, when the call drops occur, there is no error showing in the SIP ladder or within Skype reporting. The call looks clean, except for the duration being ~15 to 30 seconds

I have enabled the session time and I am waiting on the people reporting the issue provide updates today.

I had pulled the top failure reports and I am pleased to see the the top five for both the primary and secondary pool have changed from flat or increasing to not dropping.

I think I need to give it a couple days. I do think there may be an issue with a firewall port for AV. I think it only 443 that is open and I believe 3478 also needs to be open.

More to come. I will plan to update Friday after I get a little more data

0 Votes 0 ·
Show more comments
Mystryman007 avatar image
0 Votes"
Mystryman007 answered JimmyYang-MSFT commented

At this point, I dont have an specific answer as to what has improved or mitigated the issue, but I can provide what we did that we believe to be the bulk of the fix.

  1. Session Border Controller was modified to allow session update after connection. This was originally set to not supported.

  2. We modified the Session border controller of our secondary site to mirror the primary. There were several values that were not alligned.

  3. Skype for Business - After the above was completed, we waited two days and were still getting reports of drops each day. So we modified the trunk configuration to re-enable the Session Timer to True. Previously had been set to false.

Since item 3 was completed, we have not had a report of dropped calls. I believe that when this was set to true previously, it issues with items 1 and 2 were causing the misalignment and drops.

We have a session today to look at a few other items such as Stun Traffic being blocked on Port 3478 and also LyncDiscover not being found external.





· 3
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

@Mystryman007

Thanks for sharing your workarounds about this problem. Now this problem can be happened in your environment?

0 Votes 0 ·

Yes, this digging has uncovered a couple other issues. It appears there are some Proxy Rules that are being triggered that should not be.

I appreciate your follow up and input.

I am feeling fairly confident that are call drops are good now.

0 Votes 0 ·

@Mystryman007

You're welcome. I am glad to see the drop issue can be resolved. If you have any other question on Skype for Business Server, please feel free to drop us as a note.

Meanwhile, you could try to mark your answer to close the thread, it will help others who encounter the same issue and read this thread.

Thank you for your understanding and patience!

0 Votes 0 ·