A customer contacted me with an inbound call issue. Inbound calls were taking at least 30 seconds to connect, and some would not connect at all. While I've experienced call delays before, the root cause was different each time I investigated.
Since the issue was happening so frequently, I took a SIP trace from their Audio Codes Gateway. I noticed the following pattern in the SIP trace:
If everything was working correctly, *I should* see the SIP 183 answered with a '200 OK' rather than an additional SIP 183. My initial thought was, "Why isn't the carrier answering my 183 message?" I spoke with an engineer from the carrier (AT&T) and he provided logs from his end showing they were, in fact, answering my SIP 183. The customer side, however, was not sending the SIP 200 back to them.
What's going on here? The carrier's log proved they weren't causing the problem. The other time I've experienced this issue was due to a network issue. Specifically, a customer's router was looping traffic due to misconfigured routes. The traffic appeared to be routed correctly, though. What else could be causing this?
I asked the customer if any changes had been made recently. The customer mentioned they recently shutdown ports 80 & 443 to the outside due to the WannaCrypt Virus.
Bingo! We found our culprit. 😉
During the ICE (Interactive Connectivity Establisment) Negotiation for audio/video, the Edge Server provides a list of candidates to help Skype for Business find the best possible path for media. The Edge Server *must* have ports 80 & 443 open to the outside world for HTTP/HTTPS traffic. Since the customer had shut off these ports, ICE Negotiation was disrupted. Once the ports were opened via the firewall again, the inbound audio delay disappeared.