We have recently dealt with and resolved a one-way audio issue with Skype for Business and AudioCodes internally. Mirazon uses Microsoft Skype for Business 2015 Server and AudioCodes Mediant SBC for SIP Trunk service from Intelepeer. For many years, using a different vendor’s SBC, everything has been all fine and dandy with no problems; even through Lync 2010, Lync 2013, and the Skype For Business 2015 transition.
This one-way audio issue only cropped up when putting the AudioCodes SBC into service.
Previously, we’ve written about how to implement AudioCodes solutions in a Microsoft UC ecosystem. You can download the whitepaper for yourself if you would find it useful!
Anyway, there is an SBC Wizard template for configuring Skype for Business 2015 (previously Lync 2013) and Intelepeer as an ITSP. We have tried both with and without the wizard and this problem occured. It would manifest like this…
Using Microsoft UC policies, routes and PSTN usages, a set of pilot users was established to utilize the AudioCodes SBC as their phone gateway. We would make a phone call and everything would appear normal, both in action (two-way audio) and via syslog, the SIP stack/trace is all perfect. Then, approximately 30 minutes later, the phone call would enter one-way audio. The call would never drop. There is no BYE, just one-leg of the audio disappears. The call leg OUTBOUND (between Skype for Business and the AudioCodes SBC and then Intelepeer) would be perfectly heard and understood by the remote party. The call leg INBOUND (between Intelepeer and the AudioCodes SBC and then into Skype for Business) would completely disappear. But it would only disappear between AudioCodes and Skype for Business.
What, really? Yes.
During troubleshooting, Intelepeer engineering was fully engaged and even attempted a troubleshooting step using a known-to-their-hardware bug fix. That did not help us.
While troubleshooting, the phone call was traced in entirety using hardware tools, syslog tools, and even wireshark-type tools. When the one-way audio would happen, it was discovered that the traffic between Intelepeer (ITSP) and AudioCodes (SBC) was still alive. Audio was good. DTMF was good. The leg was active. It just didn’t make it back to Skype for Business.
A working theory, we suspected it was an SRTP (perhaps a rekey) issue and we tore down the Microsoft-to-AudioCodes SBC session and built it as TCP/RTP only (not TLS/SRTP). We did a new set of traces and the problem did not exist. It’s healed.
That’s fine – but why?
We engaged with our local AudioCodes engineer and he had heard of similar issues related to SRTP keys.
We navigated to the IP Profile of the Microsoft Skype for Business (Lync) IP Group and changed the following setting:
Using the SBC Wizard set this to an undesirable state. It’s possible this is a bug in the SBC Wizard, or more likely, the wizard database was out of date.
What we found was that for some unknown reason (for now) during the call leg between Skype for Business (Lync) and AudioCodes, the SRTP key would expire and never rebuild causing media to tear down on that internal leg of the call.
The external leg was unaffected.
Forcing an active rekey of SRTP fixed this one-way audio stream issue.
Again, the call never dropped, there was no BYE. The media leg was torn down because SRTP expired between AudioCodes SBC and Microsoft Skype for Business.