PSTN calls fail with too many Skype for Business delegates (or a team-call) assigned

AudioCodes, Skype for Business

Introduction

Had this one recently. Just before ‘go-live’ we had an issue whereby some users were unable to receive calls. On testing, we noticed that an affected user had delegates (or a team-call) set to ring. Disabling the delegates from receiving calls and it worked again. If the delegates were set to ring after 0 seconds, the user got a missed call each second the call was not ringing. Odd!

In this scenario there was:

  • SfB 2015 Server with latest CU
  • AudioCodes SBC
  • Gamma SIP Trunk

Trying to work out the pattern

Testing with a user that has 5 delegates set, we noticed if you removed some delegates from receiving calls to leave a certain amount e.g. 3 or less, it would start working again. Others it might only work with 2 delegates or less. Totally odd and not consistent!

The issue was also apparent whether it was set to simultaneous ring or a call forward.

Attempts to fix

We tried various things to fix it:

  • Reboot
  • We had just installed the March 2018 CU, so rolled it back
  • We had added the delegates for the user using SEFAUtil/SEFAUtilServer, so tried adding them from the client instead

At this point, it was still the same. We got a SIP Stack trace and checked it in Snooper. We could see a call being routed fine, but then Mediation was ending the call with a normal termination reason.

Lightbulb moment

Up until this point, we’d been led to believe the issue was affecting all calls to the user (PSTN and user-to-user calls). It turns out this was not the case and only PSTN was affected - should have tested this myself! OK - to the SBC.

We reproduced the issue by assigning 5 delegates and opened up the SIP flow in the AudioCodes Syslog:

One thing that immediately stood out was that SIP trunk (Gamma) was ending the call as soon as it was forwarded, not SfB! Second thing was the amount of 183’s from the Mediation server. The total of 183s after the 181 Call is being forwarded was 5 (one for each delegate). Tried with 3 delegates and the call worked but only 3 183s that time. OK, so has to be the multiple 183s being sent before 180 ringing to the SIP trunk.

I had a look at the IP Profile of the SIP trunk on the SBC and noticed a setting under Early Media - Remote Multiple 18x. Changed this to Not Supported:

Tried again and bingo calls work with 5, 6, 7 etc. delegates. This is what the SIP trace looks like now:

We now still get multiple 183s following by ringing, but the SBC only passes on the first 18x response to the SIP trunk.

As to why inconsistent with the number of delegates to cause the issue? My thought process was if a user only has 2 delegates, but those 2 have some delegates themselves, it would be enough but never got around to proving this.