Skype for Business server 2019 Odd Call Drops

Jeff Greenburg 41 Reputation points

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

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.


  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

Skype for Business
Skype for Business
A Microsoft communications service that provides communications capabilities across presence, instant messaging, audio/video calling, and an online meeting experience that includes audio, video, and web conferencing.
591 questions
0 comments No comments
{count} votes

2 answers

Sort by: Most helpful
  1. JimmyYang-MSFT 47,616 Reputation points Microsoft Vendor

    Hi @Jeff Greenburg ,

    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:

    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.

  2. Jeff Greenburg 41 Reputation points

    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.